[jira] [Updated] (CXF-8066) Support Doclet API (JDK13+)
[
https://issues.apache.org/jira/browse/CXF-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8066:
--
Description:
The com.sun.javadoc.* API is gone in JDK 13 and is replaced with Doclet API. As
such, the CXF builds are started to fail on JDK13 for
{noformat}
cxf-java2wadl-plugin{noformat}
Example:
{noformat}
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile)
on project cxf-java2wadl-plugin: Fatal error compiling: CompilerException:
NullPointerException -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn -rf :cxf-java2wadl-plugin{noformat}
(by adding the true to
maven-compiler-plugin it is possible to get the clear error).
The official migration guide:
[https://download.java.net/java/early_access/jdk13/docs/api/jdk.javadoc/jdk/javadoc/doclet/package-summary.html#migration|https://download.java.net/java/early_access/jdk13/docs/api/jdk.javadoc/jdk/javadoc/doclet/package-summary.html#migration).]
We may need to introduce the multi-release JAR since the Java 8/9/10/11 and 13+
implementation are not compatible. We are currently blocked by
'maven-javadoc-plugin' since it is still using the old API, please check out
their builds:
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/master
was:
The com.sun.javadoc.* API is gone in JDK 13 and is replaced with Doclet API. As
such, the CXF builds are started to fail on JDK13 for
{noformat}
cxf-java2wadl-plugin{noformat}
Example:
{noformat}
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile)
on project cxf-java2wadl-plugin: Fatal error compiling: CompilerException:
NullPointerException -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn -rf :cxf-java2wadl-plugin{noformat}
(by adding the true to
maven-compiler-plugin it is possible to get the clear error).
The official migration guide:
[https://download.java.net/java/early_access/jdk13/docs/api/jdk.javadoc/jdk/javadoc/doclet/package-summary.html#migration|https://download.java.net/java/early_access/jdk13/docs/api/jdk.javadoc/jdk/javadoc/doclet/package-summary.html#migration).]
We may need to introduce the multi-release JAR since the Java 8/9/10/11 and 13+
implementation are not compatible.
> Support Doclet API (JDK13+)
> ---
>
> Key: CXF-8066
> URL: https://issues.apache.org/jira/browse/CXF-8066
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
>
> The com.sun.javadoc.* API is gone in JDK 13 and is replaced with Doclet API.
> As such, the CXF builds are started to fail on JDK13 for
> {noformat}
> cxf-java2wadl-plugin{noformat}
> Example:
> {noformat}
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project cxf-java2wadl-plugin: Fatal error compiling:
> CompilerException: NullPointerException -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :cxf-java2wadl-plugin{noformat}
> (by adding the true to
> maven-compiler-plugin it is possible to get the clear error).
> The official migration guide:
>
[jira] [Commented] (CXF-8051) Request gets corrupted when calling a stateful streamed secure conversation
[ https://issues.apache.org/jira/browse/CXF-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881545#comment-16881545 ] Henning Normann commented on CXF-8051: -- It works - the token payload is sent as MTOM, and the first service call succeeds. However, if a second call is made to the service, the token payload is missing. I assume (but haven’t tested) that the same issue is with inline token payload. > Request gets corrupted when calling a stateful streamed secure conversation > --- > > Key: CXF-8051 > URL: https://issues.apache.org/jira/browse/CXF-8051 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 3.3.2 > Environment: The request is running in a console application hosted > in Netbeans on Windows Server 2012 R2. The service is a .NET WCF service on > Windows Server 2012 R2. >Reporter: Henning Normann >Assignee: Colm O hEigeartaigh >Priority: Major > Attachments: EcBad.txt, EcGood.txt, > ResponseFromSecurityTokenService.txt > > Time Spent: 10m > Remaining Estimate: 0h > > The request to a streamed secure conversation web service gets corrupted if > the service (.NET WCF) is configured as stateless (with a stateful token > carrying the state in soap cookies). If the service as configured as stateful > (no soap cookies), the request is valid. > Updated 2nd time: When the request is streamed, CXF doesn't stream the > payload of the content of the token cookie, and the reference from the cookie > is "unresolved". When the request is not-streamed, the cookie payload is > included as base64 inside the cookie element, and everything works fine. The > attached formatted requests EcBad.txt (failing from CXF) and EcGood.txt > (valid request from a .NET WCF client) show the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-8072) Loggers logs request twice in case of Fault (CXF-7518 again)
[ https://issues.apache.org/jira/browse/CXF-8072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-8072. --- Resolution: Fixed Fix Version/s: 3.2.10 3.3.3 > Loggers logs request twice in case of Fault (CXF-7518 again) > > > Key: CXF-8072 > URL: https://issues.apache.org/jira/browse/CXF-8072 > Project: CXF > Issue Type: Bug > Components: logging >Affects Versions: 3.2.9 >Reporter: Tomasz Poręba >Assignee: Freeman Fang >Priority: Minor > Fix For: 3.3.3, 3.2.10 > > > I noticed that I experience the same problem as in issue CXF-7518 but in far > newer version - 3.2.9. It seems that the fix of CXF-7562 added again the same > code that was removed in CXF-7518. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CXF-8072) Loggers logs request twice in case of Fault (CXF-7518 again)
[ https://issues.apache.org/jira/browse/CXF-8072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-8072: - Assignee: Freeman Fang > Loggers logs request twice in case of Fault (CXF-7518 again) > > > Key: CXF-8072 > URL: https://issues.apache.org/jira/browse/CXF-8072 > Project: CXF > Issue Type: Bug > Components: logging >Affects Versions: 3.2.9 >Reporter: Tomasz Poręba >Assignee: Freeman Fang >Priority: Minor > > I noticed that I experience the same problem as in issue CXF-7518 but in far > newer version - 3.2.9. It seems that the fix of CXF-7562 added again the same > code that was removed in CXF-7518. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-8072) Loggers logs request twice in case of Fault (CXF-7518 again)
Tomasz created CXF-8072: --- Summary: Loggers logs request twice in case of Fault (CXF-7518 again) Key: CXF-8072 URL: https://issues.apache.org/jira/browse/CXF-8072 Project: CXF Issue Type: Bug Components: logging Affects Versions: 3.2.9 Reporter: Tomasz I noticed that I experience the same problem as in issue CXF-7518 but in far newer version - 3.2.9. It seems that the fix of CXF-7562 added again the same code that was removed in CXF-7518. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (CXF-8071) XKMS LdapCertificateRepo searching using Service UID doesn't work
[ https://issues.apache.org/jira/browse/CXF-8071?focusedWorklogId=273964=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-273964 ] ASF GitHub Bot logged work on CXF-8071: --- Author: ASF GitHub Bot Created on: 09/Jul/19 10:27 Start Date: 09/Jul/19 10:27 Worklog Time Spent: 10m Work Description: coheigea commented on pull request #565: CXF-8071 - XKMS LdapCertificateRepo searching using Service UID doesn… URL: https://github.com/apache/cxf/pull/565 …'t work This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 273964) Time Spent: 10m Remaining Estimate: 0h > XKMS LdapCertificateRepo searching using Service UID doesn't work > - > > Key: CXF-8071 > URL: https://issues.apache.org/jira/browse/CXF-8071 > Project: CXF > Issue Type: Bug >Affects Versions: 3.2.9, 3.3.2 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.3.3, 3.2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > XKMS LdapCertificateRepo searching using Service UID doesn't work as > explained on the dev list: > https://lists.apache.org/thread.html/ad58b23cfc76ab678208196621446e961787339d41493f878b056486@%3Cdev.cxf.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-8071) XKMS LdapCertificateRepo searching using Service UID doesn't work
Colm O hEigeartaigh created CXF-8071: Summary: XKMS LdapCertificateRepo searching using Service UID doesn't work Key: CXF-8071 URL: https://issues.apache.org/jira/browse/CXF-8071 Project: CXF Issue Type: Bug Affects Versions: 3.3.2, 3.2.9 Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 3.3.3, 3.2.10 XKMS LdapCertificateRepo searching using Service UID doesn't work as explained on the dev list: https://lists.apache.org/thread.html/ad58b23cfc76ab678208196621446e961787339d41493f878b056486@%3Cdev.cxf.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-8069) CXF does not allow to change default configuration of Jetty
[
https://issues.apache.org/jira/browse/CXF-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881095#comment-16881095
]
Colm O hEigeartaigh commented on CXF-8069:
--
The SSL CipherSuites you are using above are not standard (e.g. they don't
apper here:
https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html)
- they appear to be particular to IBM. So I think this is not a CXF problem -
you will need to ask the Jetty project if they support these cipher suites, and
if so how they are configured.
> CXF does not allow to change default configuration of Jetty
> ---
>
> Key: CXF-8069
> URL: https://issues.apache.org/jira/browse/CXF-8069
> Project: CXF
> Issue Type: Bug
> Environment: CXF : 3.2.7
> Jetty: 9.4.18v20190429
> Java : IBM Java 8
> Platform : AIX
>
>Reporter: Naina
>Priority: Blocker
> Attachments: Cipher_error.png, Protocol_error.png
>
>
> Hi Team,
> We are using Apache CXF 3.2.7 and seeking help to update jetty's default
> configuration which is being used by Apache CXF.
> CXF internally calls jetty and jetty has default configuration to exclude
> cipher suites which starts with SSL_*. As all the TLS cipher suites of IBM
> Java 8 starts wih SSL_*, we are unable to establish connection with Jetty
> using IBM Java 8. So the ask is, how can we update the default configuration
> of Jetty via CXF.
> We resolved the same issue on one of our server with the help of Jetty team
> where we were creating Jetty instance in our code and were getting warning
> "No supported ciphers from [ListOfAvailableCiphers]". They suggested to add
> *sslContextFactory.setExcludeCipherSuites(ListOfWeakCiphers)* method while
> creating Jetty's instance, which actually overrides the default cipher suites
> excluded by Jetty.
> But in the current case, we just call CXF's JAXRSServerFactoryBean create()
> method which internally calls Jetty and create its instance with default
> configuration. Here is the code snippet:
> {color:#205081}_private JAXRSServerFactoryBean sf = new
> JAXRSServerFactoryBean();_{color}
> {color:#205081}_private JettyHTTPDestination startEndpoint() {_{color}
> {color:#205081} _logger.info("*+before Starting RESTful Agent+*");_{color}
> {color:#205081} _Server server = sf.create();_{color}
> {color:#205081} _logger.info("*+Started RESTful Agent at:+* " +
> server.getEndpoint().getEndpointInfo().getAddress());_{color}
> {color:#205081} _return (JettyHTTPDestination)
> server.getDestination();_{color}
> {color:#205081} _}_{color}
>
> These are the logs which got generated during the execution of above code :
> {color:#205081}_[2019-07-03T07:37:33,324-0500] INFO [main]
> com.netapp.snapcreator.agent.nextgen.RestEndpointHelper - *+before Starting
> RESTful Agent+*_{color}
> {color:#205081}_[2019-07-03T07:37:33,396-0500] INFO [main]
> org.apache.cxf.endpoint.ServerImpl - Setting the server's publish address to
> be https://localhost:9091/SnapCreator/_{color}
> {color:#205081}_[2019-07-03T07:37:33,503-0500] INFO [main]
> org.eclipse.jetty.util.log - Logging initialized @2814ms to
> org.eclipse.jetty.util.log.Slf4jLog_{color}
> {color:#205081}_[2019-07-03T07:37:33,566-0500] INFO [main]
> org.eclipse.jetty.server.Server - jetty-9.4.18.v20190429; built:
> 2019-04-29T20:42:08.989Z; git: e1bc35120a6617ee3df052294e433f3a25ce7097; jvm
> 8.0.5.21 - pap6480sr5fp21-20180830_01(SR5 FP21)_{color}
> {color:#205081}_[2019-07-03T07:37:33,746-0500] WARN [main]
> *org.eclipse.jetty.util.ssl.SslContextFactory -* *No supported ciphers from*
> [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
> SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384, SSL_RSA_WITH_AES_256_CBC_SHA256,
> SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384,
> SSL_DHE_RSA_WITH_AES_256_CBC_SHA256, SSL_DHE_DSS_WITH_AES_256_CBC_SHA256,
> SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA,
> SSL_RSA_WITH_AES_256_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
> SSL_ECDH_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_RSA_WITH_AES_256_CBC_SHA,
> SSL_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
> SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256, SSL_RSA_WITH_AES_128_CBC_SHA256,
> SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256,
> SSL_DHE_RSA_WITH_AES_128_CBC_SHA256, SSL_DHE_DSS_WITH_AES_128_CBC_SHA256,
> SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> SSL_RSA_WITH_AES_128_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
> SSL_ECDH_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA,
> SSL_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
> SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
[jira] [Commented] (CXF-8051) Request gets corrupted when calling a stateful streamed secure conversation
[ https://issues.apache.org/jira/browse/CXF-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881064#comment-16881064 ] Colm O hEigeartaigh commented on CXF-8051: -- Great! Before merging, I'd like to try something else. Could you try the PR again? I merged a fix not to inline the attachment, but to copy it to the outbound message. I'm not sure if I did the copying correctly though. > Request gets corrupted when calling a stateful streamed secure conversation > --- > > Key: CXF-8051 > URL: https://issues.apache.org/jira/browse/CXF-8051 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 3.3.2 > Environment: The request is running in a console application hosted > in Netbeans on Windows Server 2012 R2. The service is a .NET WCF service on > Windows Server 2012 R2. >Reporter: Henning Normann >Assignee: Colm O hEigeartaigh >Priority: Major > Attachments: EcBad.txt, EcGood.txt, > ResponseFromSecurityTokenService.txt > > Time Spent: 10m > Remaining Estimate: 0h > > The request to a streamed secure conversation web service gets corrupted if > the service (.NET WCF) is configured as stateless (with a stateful token > carrying the state in soap cookies). If the service as configured as stateful > (no soap cookies), the request is valid. > Updated 2nd time: When the request is streamed, CXF doesn't stream the > payload of the content of the token cookie, and the reference from the cookie > is "unresolved". When the request is not-streamed, the cookie payload is > included as base64 inside the cookie element, and everything works fine. The > attached formatted requests EcBad.txt (failing from CXF) and EcGood.txt > (valid request from a .NET WCF client) show the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
