[jira] [Commented] (CXF-7070) HTTP headers logged in debug
[
https://issues.apache.org/jira/browse/CXF-7070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564981#comment-15564981
]
Sergey Beryozkin commented on CXF-7070:
---
Sure, some headers can be considered sensitive - however completely filtering
them out will lose the log record of what the the actual Authorization/etc
values were. For example, if it is OAuth2 Bearer token which is either
encrypted or is a simple DB pointer then dropping it completely from the log
record is not ideal, similarly to the case where the logs are pushed to the
secure file system/etc.
If losing the log records of such values is what is actually needed then it has
to be done optionally IMHO (ex, if a given message or bus property is set).
> HTTP headers logged in debug
>
>
> Key: CXF-7070
> URL: https://issues.apache.org/jira/browse/CXF-7070
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Reporter: Fadi Mohsen
>
> We try to avoid logging of authorization header value in out/in requests, we
> filtered out these in interceptors, but turns out these are logged anyway in
> [CXF debug mode|
> https://github.com/apache/cxf/blob/120d20f47022a76970ff0fb9c9d7413cfe019eb2/rt/transports/http/src/main/java/org/apache/cxf/transport/http/Headers.java#L436]:
> {code}
> if (LOG.isLoggable(Level.FINE)) {
> LOG.log(Level.FINE, "Request Headers: " + headers.toString());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7083) Maven Plugins: System properties handling in ClassLoaderSwitcher breaks thread safety
Falko Modler created CXF-7083:
-
Summary: Maven Plugins: System properties handling in
ClassLoaderSwitcher breaks thread safety
Key: CXF-7083
URL: https://issues.apache.org/jira/browse/CXF-7083
Project: CXF
Issue Type: Bug
Components: Tooling
Affects Versions: 2.7.18
Environment: Apache Maven 3.3.9
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
Maven home: /usr/maven/default
Java version: 1.8.0_102, vendor: Oracle Corporation
Java home: /usr/java/jdk1.8.0_102/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "2.6.32-431.29.2.el6.x86_64", arch: "amd64", family:
"unix"
Reporter: Falko Modler
We got a rather large Maven project with a couble of modules that execute
{{cxf-codegen-plugin}}. Our builds runs in parallel mode via {{-Tx}} and
according to the JavaDoc in the plugin should be fine with that:
{code:java|title=https://github.com/apache/cxf/blob/cxf-2.7.18/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/wsdl2java/WSDL2JavaMojo.java}
/**
* @goal wsdl2java
* @phase generate-sources
* @description CXF WSDL To Java Tool
* @requiresDependencyResolution test
* @threadSafe
*/
public class WSDL2JavaMojo extends AbstractCodegenMoho {
...
{code}
But from time to time (maybe 5% of our builds) we see following exception
causing the respective build to fail:
{noformat}
[ERROR] Failed to execute goal
org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java (exampleExec) on project
example-module: Execution patientenService of goal
org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java failed.
ConcurrentModificationException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java (patientenService) on
project middleware-service-patient: Execution patientenService of goal
org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
patientenService of goal org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 11 more
Caused by: java.util.ConcurrentModificationException
at java.util.Hashtable$Enumerator.next(Hashtable.java:1378)
at java.util.HashMap.putMapEntries(HashMap.java:511)
at java.util.HashMap.(HashMap.java:489)
at
org.apache.cxf.maven_plugin.ClassLoaderSwitcher.restoreClassLoader(ClassLoaderSwitcher.java:129)
at
org.apache.cxf.maven_plugin.AbstractCodegenMoho.execute(AbstractCodegenMoho.java:326)
at
org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:524)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 12 more
[ERROR]
[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/PluginExecutionException
{noformat}
There seems to be a write access from another thread while
{{ClassLoaderSwitcher}} tries to copy the system properties:
{code:java|title=https://github.com/apache/cxf/blob/cxf-2.7.18/maven-plugins/wadl2java-plugin/src/main/java/org/apache/cxf/maven_plugin/common/ClassLoaderSwitcher.java#L131}
if (origProps != null) {
Map newProps = new HashMap(System.getProperties());
for (Object o : newProps.keySet()) {
if (!origProps.containsKey(o)) {
[jira] [Commented] (CXF-7083) Maven Plugins: System properties handling in ClassLoaderSwitcher breaks thread safety
[
https://issues.apache.org/jira/browse/CXF-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15565606#comment-15565606
]
Falko Modler commented on CXF-7083:
---
I guess a workaround would be to put the plugin into fork-mode?
> Maven Plugins: System properties handling in ClassLoaderSwitcher breaks
> thread safety
> -
>
> Key: CXF-7083
> URL: https://issues.apache.org/jira/browse/CXF-7083
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 2.7.18
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: /usr/maven/default
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_102/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-431.29.2.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>
> We got a rather large Maven project with a couble of modules that execute
> {{cxf-codegen-plugin}}. Our builds runs in parallel mode via {{-Tx}} and
> according to the JavaDoc in the plugin should be fine with that:
> {code:java|title=https://github.com/apache/cxf/blob/cxf-2.7.18/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/wsdl2java/WSDL2JavaMojo.java}
> /**
> * @goal wsdl2java
> * @phase generate-sources
> * @description CXF WSDL To Java Tool
> * @requiresDependencyResolution test
> * @threadSafe
> */
> public class WSDL2JavaMojo extends AbstractCodegenMoho {
> ...
> {code}
> But from time to time (maybe 5% of our builds) we see following exception
> causing the respective build to fail:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java (exampleExec) on project
> example-module: Execution patientenService of goal
> org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java failed.
> ConcurrentModificationException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java (patientenService) on
> project middleware-service-patient: Execution patientenService of goal
> org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> patientenService of goal org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 11 more
> Caused by: java.util.ConcurrentModificationException
> at java.util.Hashtable$Enumerator.next(Hashtable.java:1378)
> at java.util.HashMap.putMapEntries(HashMap.java:511)
> at java.util.HashMap.(HashMap.java:489)
> at
> org.apache.cxf.maven_plugin.ClassLoaderSwitcher.restoreClassLoader(ClassLoaderSwitcher.java:129)
> at
> org.apache.cxf.maven_plugin.AbstractCodegenMoho.execute(AbstractCodegenMoho.java:326)
> at
> org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:524)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 12 more
> [ERROR]
> [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/PluginExecutionException
> {noformat}
> There seems to be a write access from another thre
[jira] [Updated] (CXF-7083) Maven Plugins: System properties handling in ClassLoaderSwitcher breaks thread safety
[
https://issues.apache.org/jira/browse/CXF-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated CXF-7083:
--
Description:
We got a rather large Maven project with a couble of modules that execute
{{cxf-codegen-plugin}}. Our builds runs in parallel mode via {{-Tx}} and
according to the JavaDoc the plugin should be fine with that:
{code:java|title=https://github.com/apache/cxf/blob/cxf-2.7.18/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/wsdl2java/WSDL2JavaMojo.java}
/**
* @goal wsdl2java
* @phase generate-sources
* @description CXF WSDL To Java Tool
* @requiresDependencyResolution test
* @threadSafe
*/
public class WSDL2JavaMojo extends AbstractCodegenMoho {
...
{code}
But from time to time (maybe 5% of our builds) we see following exception
causing the respective build to fail:
{noformat}
[ERROR] Failed to execute goal
org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java (exampleExec) on project
example-module: Execution patientenService of goal
org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java failed.
ConcurrentModificationException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java (patientenService) on
project middleware-service-patient: Execution patientenService of goal
org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
patientenService of goal org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 11 more
Caused by: java.util.ConcurrentModificationException
at java.util.Hashtable$Enumerator.next(Hashtable.java:1378)
at java.util.HashMap.putMapEntries(HashMap.java:511)
at java.util.HashMap.(HashMap.java:489)
at
org.apache.cxf.maven_plugin.ClassLoaderSwitcher.restoreClassLoader(ClassLoaderSwitcher.java:129)
at
org.apache.cxf.maven_plugin.AbstractCodegenMoho.execute(AbstractCodegenMoho.java:326)
at
org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:524)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 12 more
[ERROR]
[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/PluginExecutionException
{noformat}
There seems to be a write access from another thread while
{{ClassLoaderSwitcher}} tries to copy the system properties:
{code:java|title=https://github.com/apache/cxf/blob/cxf-2.7.18/maven-plugins/wadl2java-plugin/src/main/java/org/apache/cxf/maven_plugin/common/ClassLoaderSwitcher.java#L131}
if (origProps != null) {
Map newProps = new HashMap(System.getProperties());
for (Object o : newProps.keySet()) {
if (!origProps.containsKey(o)) {
System.clearProperty(o.toString());
}
}
System.getProperties().putAll(origProps);
}
{code}
*Possible solutions*:
- synchronize on {{System.getProperties()}} in the entire block (lines 129-135)
- create a clone
{code:java}
(Properties) System.getProperties().clone()
{code}
and instead of {{.putAll()}} use {{.setProperties(...)}}
I haven't checked {{ClassLoaderSwitcher .switchClassLoader()}} but I guess
something similar needs to be done there.
was:
We got a rather large Maven project with a couble of modules that execute
{{c
[jira] [Created] (CXF-7084) Pass a value for the KeyName element from the XmlSecOutInterceptor to Santuario
Hugo Trippaers created CXF-7084: --- Summary: Pass a value for the KeyName element from the XmlSecOutInterceptor to Santuario Key: CXF-7084 URL: https://issues.apache.org/jira/browse/CXF-7084 Project: CXF Issue Type: New Feature Components: JAX-RS Security Reporter: Hugo Trippaers Priority: Minor This relates to issue SANTUARIO-452. The idea is that it is possible to configure a value for the KeyName in the properties that will eventually end up in the KeyInfo/KeyName field. Together with CXF-7080 this provides enough support to handle signing of XML documents where the KeyIdentifier needs to be KeyName. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7084) Pass a value for the KeyName element from the XmlSecOutInterceptor to Santuario
[ https://issues.apache.org/jira/browse/CXF-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15565659#comment-15565659 ] ASF GitHub Bot commented on CXF-7084: - GitHub user spark404 opened a pull request: https://github.com/apache/cxf/pull/176 CXF-7084 Add a configurable KeyName value using the properties I've added properties to EncryptionProperties and SignatureProperties and also two new SecurityConstants. This way a KeyName can be directly configured from the *Properties but also configured per message using a property. The Message configuration has a higher preference if both are set. You can merge this pull request into a Git repository by running: $ git pull https://github.com/spark404/cxf CXF-7084 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/176.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #176 commit c297508e7e3b4e69c0824a6faa846ab1e54cd9b1 Author: Hugo Trippaers Date: 2016-10-11T14:52:42Z CXF-7084 Add a configurable KeyName value using the properties > Pass a value for the KeyName element from the XmlSecOutInterceptor to > Santuario > --- > > Key: CXF-7084 > URL: https://issues.apache.org/jira/browse/CXF-7084 > Project: CXF > Issue Type: New Feature > Components: JAX-RS Security >Reporter: Hugo Trippaers >Priority: Minor > > This relates to issue SANTUARIO-452. The idea is that it is possible to > configure a value for the KeyName in the properties that will eventually end > up in the KeyInfo/KeyName field. > Together with CXF-7080 this provides enough support to handle signing of XML > documents where the KeyIdentifier needs to be KeyName. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7084) Pass a value for the KeyName element from the XmlSecOutInterceptor to Santuario
[ https://issues.apache.org/jira/browse/CXF-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15565672#comment-15565672 ] ASF GitHub Bot commented on CXF-7084: - Github user spark404 commented on the issue: https://github.com/apache/cxf/pull/176 Note that this ties directly to https://github.com/apache/santuario-java/pull/7 and requires an update to the WSS4J snapshot to reference the xmlsec snapshot. So compile will fail, but i wanted to have this pull request here to show the intended usage of the santuario fix. > Pass a value for the KeyName element from the XmlSecOutInterceptor to > Santuario > --- > > Key: CXF-7084 > URL: https://issues.apache.org/jira/browse/CXF-7084 > Project: CXF > Issue Type: New Feature > Components: JAX-RS Security >Reporter: Hugo Trippaers >Priority: Minor > > This relates to issue SANTUARIO-452. The idea is that it is possible to > configure a value for the KeyName in the properties that will eventually end > up in the KeyInfo/KeyName field. > Together with CXF-7080 this provides enough support to handle signing of XML > documents where the KeyIdentifier needs to be KeyName. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-7084) Pass a value for the KeyName element from the XmlSecOutInterceptor to Santuario
[ https://issues.apache.org/jira/browse/CXF-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-7084: Assignee: Colm O hEigeartaigh > Pass a value for the KeyName element from the XmlSecOutInterceptor to > Santuario > --- > > Key: CXF-7084 > URL: https://issues.apache.org/jira/browse/CXF-7084 > Project: CXF > Issue Type: New Feature > Components: JAX-RS Security >Reporter: Hugo Trippaers >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.2.0 > > > This relates to issue SANTUARIO-452. The idea is that it is possible to > configure a value for the KeyName in the properties that will eventually end > up in the KeyInfo/KeyName field. > Together with CXF-7080 this provides enough support to handle signing of XML > documents where the KeyIdentifier needs to be KeyName. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-7084) Pass a value for the KeyName element from the XmlSecOutInterceptor to Santuario
[ https://issues.apache.org/jira/browse/CXF-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-7084: - Fix Version/s: 3.2.0 > Pass a value for the KeyName element from the XmlSecOutInterceptor to > Santuario > --- > > Key: CXF-7084 > URL: https://issues.apache.org/jira/browse/CXF-7084 > Project: CXF > Issue Type: New Feature > Components: JAX-RS Security >Reporter: Hugo Trippaers >Priority: Minor > Fix For: 3.2.0 > > > This relates to issue SANTUARIO-452. The idea is that it is possible to > configure a value for the KeyName in the properties that will eventually end > up in the KeyInfo/KeyName field. > Together with CXF-7080 this provides enough support to handle signing of XML > documents where the KeyIdentifier needs to be KeyName. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7084) Pass a value for the KeyName element from the XmlSecOutInterceptor to Santuario
[ https://issues.apache.org/jira/browse/CXF-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15565714#comment-15565714 ] Colm O hEigeartaigh commented on CXF-7084: -- Review + apply once we pick up next WSS4J release which contains Santuario 2.0.8. > Pass a value for the KeyName element from the XmlSecOutInterceptor to > Santuario > --- > > Key: CXF-7084 > URL: https://issues.apache.org/jira/browse/CXF-7084 > Project: CXF > Issue Type: New Feature > Components: JAX-RS Security >Reporter: Hugo Trippaers >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.2.0 > > > This relates to issue SANTUARIO-452. The idea is that it is possible to > configure a value for the KeyName in the properties that will eventually end > up in the KeyInfo/KeyName field. > Together with CXF-7080 this provides enough support to handle signing of XML > documents where the KeyIdentifier needs to be KeyName. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-5855) Introduce support for Server Sent Events (Server)
[ https://issues.apache.org/jira/browse/CXF-5855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-5855: -- Fix Version/s: 3.2.0 Component/s: JAX-RS Summary: Introduce support for Server Sent Events (Server) (was: Introduce support for Server Sent Events) Hi Andriy, can you please resolve it, I'll create another JIRA for a client side, thanks > Introduce support for Server Sent Events (Server) > - > > Key: CXF-5855 > URL: https://issues.apache.org/jira/browse/CXF-5855 > Project: CXF > Issue Type: Sub-task > Components: JAX-RS, Transports >Reporter: Sergey Beryozkin >Assignee: Andriy Redko > Fix For: 3.2.0 > > > We now have a good WebSocket transport support. It would be good to get > Server Sent Events (SSE) supported on top of it, I believe Atmosphere does > support SSE. > SSE has been voted as one of the most interesting technologies in EE 8 plans > and support for it will very likely be required in JAX-RS. Jersey leads the > way with its SSE support already > The development is happening in `master-jaxrs-2.1` branch as SSE becomes a > part of JAX-RS 2.1 specification (in SNAPSHOT stage right now). > Server-side support is already in operational state and is built on top of > Atmosphere. > Example projects are available: > - samples/jax_rs/sse_cdi > - samples/jax_rs/sse_tomcat > - samples/jax_rs/sse_spring -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7085) Introduce support for Server Sent Events (Client)
Sergey Beryozkin created CXF-7085: - Summary: Introduce support for Server Sent Events (Client) Key: CXF-7085 URL: https://issues.apache.org/jira/browse/CXF-7085 Project: CXF Issue Type: Sub-task Components: JAX-RS, Transports Reporter: Sergey Beryozkin Fix For: 3.2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6881) Implement JAX-RS 2.1
[ https://issues.apache.org/jira/browse/CXF-6881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-6881: -- Component/s: JAX-RS > Implement JAX-RS 2.1 > > > Key: CXF-6881 > URL: https://issues.apache.org/jira/browse/CXF-6881 > Project: CXF > Issue Type: Task > Components: JAX-RS >Reporter: Sergey Beryozkin > Fix For: 3.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-6833) support RxJava Observable in return values as a more composeable alternative to Future
[
https://issues.apache.org/jira/browse/CXF-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin reassigned CXF-6833:
-
Assignee: Sergey Beryozkin
> support RxJava Observable in return values as a more composeable
> alternative to Future
>
>
> Key: CXF-6833
> URL: https://issues.apache.org/jira/browse/CXF-6833
> Project: CXF
> Issue Type: Sub-task
> Components: JAX-RS
>Reporter: james strachan
>Assignee: Sergey Beryozkin
> Fix For: 3.2.0
>
>
> when invoking multiple REST services concurrently in a microservice kinda
> world it can be really helpful to use RxJava's Observable so that you can
> easily compose concurrent asynchronous requests together.
> e.g. see this blog:
> http://joluet.github.io/blog/2014/07/07/rxjava-retrofit/
> Its basically about using RxJava's Observable as the result type; which is
> a little like a Future but can handle streams of values and is composable.
> It would be great to do this both on the client and server side; as a server
> may invoke multiple asynchronous back ends and return a composition of
> results etc.
> e.g.
> {code}
> @GET("/session.json")
> Observable login();
> @GET("/user.json")
> Observable getUserState();
> {code}
> you can then use the Observable composition methods to join / flatMap to
> compose multiple requests across different microservice invocations together
> with timeouts etc e.g. to compose the latest from 2 calls:
> {code}
> Observable.combineLatest(api.fetchUserProfile(), api.getUserState(),
> (user, userStatus) -> new Pair<>(user, userStatus));
> {code}
> and you're done! There's support for timeouts and other kinds of composition
> mechanisms too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CXF-6833) support RxJava Observable in return values as a more composeable alternative to Future
[
https://issues.apache.org/jira/browse/CXF-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin reassigned CXF-6833:
-
Assignee: Sergey Beryozkin
> support RxJava Observable in return values as a more composeable
> alternative to Future
>
>
> Key: CXF-6833
> URL: https://issues.apache.org/jira/browse/CXF-6833
> Project: CXF
> Issue Type: Sub-task
> Components: JAX-RS
>Reporter: james strachan
>Assignee: Sergey Beryozkin
> Fix For: 3.2.0
>
>
> when invoking multiple REST services concurrently in a microservice kinda
> world it can be really helpful to use RxJava's Observable so that you can
> easily compose concurrent asynchronous requests together.
> e.g. see this blog:
> http://joluet.github.io/blog/2014/07/07/rxjava-retrofit/
> Its basically about using RxJava's Observable as the result type; which is
> a little like a Future but can handle streams of values and is composable.
> It would be great to do this both on the client and server side; as a server
> may invoke multiple asynchronous back ends and return a composition of
> results etc.
> e.g.
> {code}
> @GET("/session.json")
> Observable login();
> @GET("/user.json")
> Observable getUserState();
> {code}
> you can then use the Observable composition methods to join / flatMap to
> compose multiple requests across different microservice invocations together
> with timeouts etc e.g. to compose the latest from 2 calls:
> {code}
> Observable.combineLatest(api.fetchUserProfile(), api.getUserState(),
> (user, userStatus) -> new Pair<>(user, userStatus));
> {code}
> and you're done! There's support for timeouts and other kinds of composition
> mechanisms too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6889) Support CompletionStage RxInvoker
[ https://issues.apache.org/jira/browse/CXF-6889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6889. --- Resolution: Fixed Assignee: Sergey Beryozkin (was: Andriy Redko) > Support CompletionStage RxInvoker > - > > Key: CXF-6889 > URL: https://issues.apache.org/jira/browse/CXF-6889 > Project: CXF > Issue Type: Sub-task > Components: JAX-RS >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 3.2.0 > > > https://github.com/jax-rs/api/blob/master/jaxrs-api/src/main/java/javax/ws/rs/client/Invocation.java#L298 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6798) JAXRS 2.0 Clients do not support ParamConverters
[ https://issues.apache.org/jira/browse/CXF-6798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15565875#comment-15565875 ] Andrei Ivanov commented on CXF-6798: Seeing that CXF devs started work on the 2.1 API, I noticed that there are still 2.0 parts missing :) Do you know of any plans to fix this? Are there any other parts missing from 2.0? > JAXRS 2.0 Clients do not support ParamConverters > > > Key: CXF-6798 > URL: https://issues.apache.org/jira/browse/CXF-6798 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Reporter: Sergey Beryozkin > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-7083) Maven Plugins: System properties handling in ClassLoaderSwitcher breaks thread safety
[
https://issues.apache.org/jira/browse/CXF-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated CXF-7083:
--
Description:
We got a rather large Maven project with a couble of modules that execute
{{cxf-codegen-plugin}}. Our builds runs in parallel mode via {{-Tx}} and
according to the JavaDoc the plugin should be fine with that:
{code:java|title=https://github.com/apache/cxf/blob/cxf-2.7.18/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/wsdl2java/WSDL2JavaMojo.java}
/**
* @goal wsdl2java
* @phase generate-sources
* @description CXF WSDL To Java Tool
* @requiresDependencyResolution test
* @threadSafe
*/
public class WSDL2JavaMojo extends AbstractCodegenMoho {
...
{code}
But from time to time (maybe 5% of our builds) we see following exception
causing the respective build to fail:
{noformat}
[ERROR] Failed to execute goal
org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java (exampleExec) on project
example-module: Execution exampleService of goal
org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java failed.
ConcurrentModificationException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java (exampleExec) on project
example-module: Execution exampleService of goal
org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
exampleService of goal org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 11 more
Caused by: java.util.ConcurrentModificationException
at java.util.Hashtable$Enumerator.next(Hashtable.java:1378)
at java.util.HashMap.putMapEntries(HashMap.java:511)
at java.util.HashMap.(HashMap.java:489)
at
org.apache.cxf.maven_plugin.ClassLoaderSwitcher.restoreClassLoader(ClassLoaderSwitcher.java:129)
at
org.apache.cxf.maven_plugin.AbstractCodegenMoho.execute(AbstractCodegenMoho.java:326)
at
org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:524)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 12 more
[ERROR]
[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/PluginExecutionException
{noformat}
There seems to be a write access from another thread while
{{ClassLoaderSwitcher}} tries to copy the system properties:
{code:java|title=https://github.com/apache/cxf/blob/cxf-2.7.18/maven-plugins/wadl2java-plugin/src/main/java/org/apache/cxf/maven_plugin/common/ClassLoaderSwitcher.java#L131}
if (origProps != null) {
Map newProps = new HashMap(System.getProperties());
for (Object o : newProps.keySet()) {
if (!origProps.containsKey(o)) {
System.clearProperty(o.toString());
}
}
System.getProperties().putAll(origProps);
}
{code}
*Possible solutions*:
- synchronize on {{System.getProperties()}} in the entire block (lines 129-135)
- create a clone
{code:java}
(Properties) System.getProperties().clone()
{code}
and instead of {{.putAll()}} use {{.setProperties(...)}}
I haven't checked {{ClassLoaderSwitcher .switchClassLoader()}} but I guess
something similar needs to be done there.
was:
We got a rather large Maven project with a couble of modules that execute
{{cxf-codegen-plugin}}. Ou
[jira] [Updated] (CXF-7083) Maven Plugins: System properties handling in ClassLoaderSwitcher breaks thread safety
[
https://issues.apache.org/jira/browse/CXF-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated CXF-7083:
--
Description:
We got a rather large Maven project with a couble of modules that execute
{{cxf-codegen-plugin}}. Our builds runs in parallel mode via {{-Tx}} and
according to the JavaDoc the plugin should be fine with that:
{code:java|title=https://github.com/apache/cxf/blob/cxf-2.7.18/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/wsdl2java/WSDL2JavaMojo.java}
/**
* @goal wsdl2java
* @phase generate-sources
* @description CXF WSDL To Java Tool
* @requiresDependencyResolution test
* @threadSafe
*/
public class WSDL2JavaMojo extends AbstractCodegenMoho {
...
{code}
But from time to time (maybe 5% of our builds) we see following exception
causing the respective build to fail:
{noformat}
[ERROR] Failed to execute goal
org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java (exampleExec) on project
example-module: Execution exampleService of goal
org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java failed.
ConcurrentModificationException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java (exampleExec) on project
example-module: Execution exampleService of goal
org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
patientenService of goal org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 11 more
Caused by: java.util.ConcurrentModificationException
at java.util.Hashtable$Enumerator.next(Hashtable.java:1378)
at java.util.HashMap.putMapEntries(HashMap.java:511)
at java.util.HashMap.(HashMap.java:489)
at
org.apache.cxf.maven_plugin.ClassLoaderSwitcher.restoreClassLoader(ClassLoaderSwitcher.java:129)
at
org.apache.cxf.maven_plugin.AbstractCodegenMoho.execute(AbstractCodegenMoho.java:326)
at
org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:524)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 12 more
[ERROR]
[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/PluginExecutionException
{noformat}
There seems to be a write access from another thread while
{{ClassLoaderSwitcher}} tries to copy the system properties:
{code:java|title=https://github.com/apache/cxf/blob/cxf-2.7.18/maven-plugins/wadl2java-plugin/src/main/java/org/apache/cxf/maven_plugin/common/ClassLoaderSwitcher.java#L131}
if (origProps != null) {
Map newProps = new HashMap(System.getProperties());
for (Object o : newProps.keySet()) {
if (!origProps.containsKey(o)) {
System.clearProperty(o.toString());
}
}
System.getProperties().putAll(origProps);
}
{code}
*Possible solutions*:
- synchronize on {{System.getProperties()}} in the entire block (lines 129-135)
- create a clone
{code:java}
(Properties) System.getProperties().clone()
{code}
and instead of {{.putAll()}} use {{.setProperties(...)}}
I haven't checked {{ClassLoaderSwitcher .switchClassLoader()}} but I guess
something similar needs to be done there.
was:
We got a rather large Maven project with a couble of modules that execute
{{cxf-codegen-plugin}}.
[jira] [Commented] (CXF-7075) Remove unnecessary string.length() and map.containsKey(...) calls to improve performance
[ https://issues.apache.org/jira/browse/CXF-7075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15565921#comment-15565921 ] Andy McCright commented on CXF-7075: Hi Sergey, The results from the benchmark are in and the new code does not have any impact on performance. Let's pull out the changes to JAXRSUtils. Then I think we can close out this JIRA. Thanks again, Andy > Remove unnecessary string.length() and map.containsKey(...) calls to improve > performance > > > Key: CXF-7075 > URL: https://issues.apache.org/jira/browse/CXF-7075 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.7 >Reporter: Andy McCright >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.8, 3.0.11 > > Attachments: JAXRSUtils-parseMediaType-perfTest.zip > > Original Estimate: 24h > Remaining Estimate: 24h > > Using a simple (echo) JAX-RS benchmark, we've found a few hot spots around > string.length() and map.containsKey(...) calls that could be optimized. > Initial testing with the proposed changes yielded about a 2-3% improvement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7086) Dynamically load signature validation keys using KeyName
Hugo Trippaers created CXF-7086: --- Summary: Dynamically load signature validation keys using KeyName Key: CXF-7086 URL: https://issues.apache.org/jira/browse/CXF-7086 Project: CXF Issue Type: New Feature Components: JAX-RS Security Reporter: Hugo Trippaers Priority: Minor The current implementation of handling incoming messages with a KeyName identifier is to rely on a single "default" key. The SignatureValidationKey. However it is possible to have multiple different KeyNames and the expected behaviour is to select the right certificate based on the KeyName. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-5855) Introduce support for Server Sent Events (Server)
[ https://issues.apache.org/jira/browse/CXF-5855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15565936#comment-15565936 ] Andriy Redko commented on CXF-5855: --- Hey Sergey, Sure, thanks! > Introduce support for Server Sent Events (Server) > - > > Key: CXF-5855 > URL: https://issues.apache.org/jira/browse/CXF-5855 > Project: CXF > Issue Type: Sub-task > Components: JAX-RS, Transports >Reporter: Sergey Beryozkin >Assignee: Andriy Redko > Fix For: 3.2.0 > > > We now have a good WebSocket transport support. It would be good to get > Server Sent Events (SSE) supported on top of it, I believe Atmosphere does > support SSE. > SSE has been voted as one of the most interesting technologies in EE 8 plans > and support for it will very likely be required in JAX-RS. Jersey leads the > way with its SSE support already > The development is happening in `master-jaxrs-2.1` branch as SSE becomes a > part of JAX-RS 2.1 specification (in SNAPSHOT stage right now). > Server-side support is already in operational state and is built on top of > Atmosphere. > Example projects are available: > - samples/jax_rs/sse_cdi > - samples/jax_rs/sse_tomcat > - samples/jax_rs/sse_spring -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-5855) Introduce support for Server Sent Events (Server)
[ https://issues.apache.org/jira/browse/CXF-5855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-5855. --- Resolution: Fixed > Introduce support for Server Sent Events (Server) > - > > Key: CXF-5855 > URL: https://issues.apache.org/jira/browse/CXF-5855 > Project: CXF > Issue Type: Sub-task > Components: JAX-RS, Transports >Reporter: Sergey Beryozkin >Assignee: Andriy Redko > Fix For: 3.2.0 > > > We now have a good WebSocket transport support. It would be good to get > Server Sent Events (SSE) supported on top of it, I believe Atmosphere does > support SSE. > SSE has been voted as one of the most interesting technologies in EE 8 plans > and support for it will very likely be required in JAX-RS. Jersey leads the > way with its SSE support already > The development is happening in `master-jaxrs-2.1` branch as SSE becomes a > part of JAX-RS 2.1 specification (in SNAPSHOT stage right now). > Server-side support is already in operational state and is built on top of > Atmosphere. > Example projects are available: > - samples/jax_rs/sse_cdi > - samples/jax_rs/sse_tomcat > - samples/jax_rs/sse_spring -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7083) Maven Plugins: System properties handling in ClassLoaderSwitcher breaks thread safety
[
https://issues.apache.org/jira/browse/CXF-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15565946#comment-15565946
]
Falko Modler commented on CXF-7083:
---
Doesn't seem so, the mojo invokes {{ClassLoaderSwitcher}} regardless of the
fork setting:
{code:java|title=https://github.com/apache/cxf/blob/cxf-2.7.18/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/AbstractCodegenMoho.java#L300}
ClassLoaderSwitcher classLoaderSwitcher = new
ClassLoaderSwitcher(getLog());
boolean result = true;
Bus bus = null;
try {
Set cp = classLoaderSwitcher.switchClassLoader(project,
useCompileClasspath, classesDir);
if ("once".equals(fork) || "true".equals(fork)) {
forkOnce(cp, effectiveWsdlOptions);
} else {
for (GenericWsdlOption o : effectiveWsdlOptions) {
bus = generate(o, bus, cp);
File dirs[] = o.getDeleteDirs();
if (dirs != null) {
for (int idx = 0; idx < dirs.length; ++idx) {
result = result && deleteDir(dirs[idx]);
}
}
}
}
} finally {
// cleanup as much as we can.
if (bus != null) {
bus.shutdown(true);
}
classLoaderSwitcher.restoreClassLoader();
restoreProxySetting(originalProxyHost, originalProxyPort,
originalNonProxyHosts,
originalProxyUser, originalProxyPassword);
}
{code}
> Maven Plugins: System properties handling in ClassLoaderSwitcher breaks
> thread safety
> -
>
> Key: CXF-7083
> URL: https://issues.apache.org/jira/browse/CXF-7083
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 2.7.18
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: /usr/maven/default
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_102/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-431.29.2.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>
> We got a rather large Maven project with a couble of modules that execute
> {{cxf-codegen-plugin}}. Our builds runs in parallel mode via {{-Tx}} and
> according to the JavaDoc the plugin should be fine with that:
> {code:java|title=https://github.com/apache/cxf/blob/cxf-2.7.18/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/wsdl2java/WSDL2JavaMojo.java}
> /**
> * @goal wsdl2java
> * @phase generate-sources
> * @description CXF WSDL To Java Tool
> * @requiresDependencyResolution test
> * @threadSafe
> */
> public class WSDL2JavaMojo extends AbstractCodegenMoho {
> ...
> {code}
> But from time to time (maybe 5% of our builds) we see following exception
> causing the respective build to fail:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java (exampleExec) on project
> example-module: Execution exampleService of goal
> org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java failed.
> ConcurrentModificationException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java (exampleExec) on
> project example-module: Execution exampleService of goal
> org.apache.cxf:cxf-codegen-plugin:2.7.18:wsdl2java failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.maven.plugin.PluginExecutio
[jira] [Commented] (CXF-7086) Dynamically load signature validation keys using KeyName
[ https://issues.apache.org/jira/browse/CXF-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15565958#comment-15565958 ] ASF GitHub Bot commented on CXF-7086: - GitHub user spark404 opened a pull request: https://github.com/apache/cxf/pull/177 CXF-7086 Add a Map with KeyNames and aliases to configure xmlsec This patch is related to https://github.com/apache/santuario-java/pull/8 The goal is to have a solution where the "user" of the XmlSecInInterceptor can specify a map of KeyNames and the keystore aliases that contain the keys to use during the signature validation. (and possibly also decryption, but that i haven't looked at yet) Looking for feedback You can merge this pull request into a Git repository by running: $ git pull https://github.com/spark404/cxf CXF-7086 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/177.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #177 commit c297508e7e3b4e69c0824a6faa846ab1e54cd9b1 Author: Hugo Trippaers Date: 2016-10-11T14:52:42Z CXF-7084 Add a configurable KeyName value using the properties commit 2562213e6c8710201a70e9dd40374af5521a9607 Author: Hugo Trippaers Date: 2016-10-11T16:45:02Z CXF-7086 Use a map of KeyName and aliases to fill the KeyName lookup map in the XMLSecurityProperties > Dynamically load signature validation keys using KeyName > > > Key: CXF-7086 > URL: https://issues.apache.org/jira/browse/CXF-7086 > Project: CXF > Issue Type: New Feature > Components: JAX-RS Security >Reporter: Hugo Trippaers >Priority: Minor > > The current implementation of handling incoming messages with a KeyName > identifier is to rely on a single "default" key. The SignatureValidationKey. > However it is possible to have multiple different KeyNames and the expected > behaviour is to select the right certificate based on the KeyName. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
