[jira] [Commented] (CXF-6622) Enhance Failover Feature to support Netflix Hystrix

2015-11-04 Thread Andriy Redko (JIRA) 

[ 
https://issues.apache.org/jira/browse/CXF-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14990958#comment-14990958
 ] 

Andriy Redko commented on CXF-6622:
---

Hi Sergey,

It seems like I have found a perfect much in a form of Apache Zest 
(http://zest.apache.org/). This project provides a lot of building blocks, 
including CircuitBreaker implementation. I am working on full-fledged 
integration and configuration, looks very straightforward and all our failover 
tests are passing already.

Thanks!

Best Regards,
Andriy Redko

> Enhance Failover Feature to support Netflix Hystrix
> ---
>
> Key: CXF-6622
> URL: https://issues.apache.org/jira/browse/CXF-6622
> Project: CXF
>  Issue Type: New Feature
>Reporter: Sergey Beryozkin
>Assignee: Andriy Redko
> Fix For: NeedMoreInfo
>
> Attachments: hystrix_cc_failover.patch
>
>
> The interest in supporting Netflix Hystrix in CXF grows



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CXF-6665) ClassCastException in SoapActionInInterceptor

2015-11-04 Thread Tom Cunningham (JIRA) 
Tom Cunningham created CXF-6665:
---

 Summary: ClassCastException in SoapActionInInterceptor
 Key: CXF-6665
 URL: https://issues.apache.org/jira/browse/CXF-6665
 Project: CXF
  Issue Type: Bug
  Components: Soap Binding
Affects Versions: 2.7.17
Reporter: Tom Cunningham


Seeing a ClassCastException in SoapActionInInterceptor after upgrading to cxf 
2.7.17.I do not see this error in previous versions of CXF - it looks like 
this is caused by the changes in CXF-6433.

02:54:00,882 WARN  [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor for 
{urn:switchyard-quickstart:soap-attachment:1.0}ImageServiceService has thrown 
exception, unwinding now
java.lang.ClassCastException: javax.mail.internet.InternetHeaders cannot be 
cast to java.util.Map
at 
org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.getSoapAction(SoapActionInInterceptor.java:86)
at 
org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:121)
at 
org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor.handleMessage(SoapActionInInterceptor.java:45)
at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
at 
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:355)
at 
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:319)
at 
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:66)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1088)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1024)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:370)
at 
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
at 
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)
at 
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
at 
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at 
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)
at 
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CXF-6664) NullpointerException in LinkBuilderImpl#getResolvedUri when linkheader url has a matrix parameter

2015-11-04 Thread Michael Krenn (JIRA) 
Michael Krenn created CXF-6664:
--

 Summary: NullpointerException in LinkBuilderImpl#getResolvedUri 
when linkheader url has a matrix parameter
 Key: CXF-6664
 URL: https://issues.apache.org/jira/browse/CXF-6664
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS
Affects Versions: 3.0.3
Reporter: Michael Krenn


The method LinkBuilderImpl#link(String) has a bug when in url between "<" and 
">" a matrix parameter (begins with ";") is occuring.

Then the tokenizer splits the url at ";" and no "UriBuilder.fromUri" is called.
when accessing "ub" in getResolvedUri, a NullPointerException is thrown.

Example:
* LinkHeader Entry:

;rel="all";title="Read
 all resources";type="application/json";verb="GET"

* StackTrace:

java.lang.NullPointerException
at 
org.apache.cxf.jaxrs.impl.LinkBuilderImpl.getResolvedUri(LinkBuilderImpl.java:58)
at 
org.apache.cxf.jaxrs.impl.LinkBuilderImpl.build(LinkBuilderImpl.java:46)
at javax.ws.rs.core.Link.valueOf(Link.java:174)
at 
org.apache.cxf.jaxrs.impl.ResponseImpl.getAllLinks(ResponseImpl.java:362)
at org.apache.cxf.jaxrs.impl.ResponseImpl.getLink(ResponseImpl.java:305)


Following Patch of "LinkBuilderImpl#link(String)" supports this case:

@Override
public Builder link(String link) {
String[] tokens = StringUtils.split(link, ";");
String potentialUrlPart = null;

for (String token : tokens) {

if (potentialUrlPart != null) {
token = potentialUrlPart + token;
potentialUrlPart = null;
}

String theToken = token.trim();

if (theToken.startsWith("<") && theToken.endsWith(">")) {
ub = UriBuilder.fromUri(theToken.substring(1, theToken.length() 
- 1));
} else {
int i = theToken.indexOf('=');
if (i != -1) {
String name = theToken.substring(0, i);
String value = stripQuotes(theToken.substring(i + 1));
params.put(name, value);
} else {
potentialUrlPart = token;
}
}
}
return this;
}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CXF-6663) Scope based authorization support for OAuth2 RS endpoints

2015-11-04 Thread Sergey Beryozkin (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CXF-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Beryozkin updated CXF-6663:
--
Description: Annotations like @ConfidentialClient, @Scopes("a", "b") should 
 be used in the combinations or separately, ex, this method can only be invoked 
if the client behind this access token is confidential, and/or this client has 
'a' and 'b' scopes approved. OAuth2 filter can already do some fine-grained 
authorization (restrict to specific HTTP verbs or URI subsets) and the RS code 
can use OauthContext to manually check the scopes, the client type, etc, but 
the annotation-based AC would be quite handy too  (was: Annotations like 
@ConfidentialClient, @Scopes("a", "b") should  be used in the combinations or 
separately, ex, this method can only be invoked if the client behind this 
access token is confidential, and/or this client has 'a' and 'b' scopes 
approved. OAuth2 filter can already so some fine-grained authorization 
(restrict to specific HTTP verbs or URI subsets) and the RS code can use 
OauthContext to manually check the scopes, the client type, etc, but the 
annotation-based AC would be quite handy too)

> Scope based authorization support for OAuth2 RS endpoints
> -
>
> Key: CXF-6663
> URL: https://issues.apache.org/jira/browse/CXF-6663
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS Security
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>
> Annotations like @ConfidentialClient, @Scopes("a", "b") should  be used in 
> the combinations or separately, ex, this method can only be invoked if the 
> client behind this access token is confidential, and/or this client has 'a' 
> and 'b' scopes approved. OAuth2 filter can already do some fine-grained 
> authorization (restrict to specific HTTP verbs or URI subsets) and the RS 
> code can use OauthContext to manually check the scopes, the client type, etc, 
> but the annotation-based AC would be quite handy too



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CXF-6663) Scope based authorization support for OAuth2 RS endpoints

2015-11-04 Thread Sergey Beryozkin (JIRA) 
Sergey Beryozkin created CXF-6663:
-

 Summary: Scope based authorization support for OAuth2 RS endpoints
 Key: CXF-6663
 URL: https://issues.apache.org/jira/browse/CXF-6663
 Project: CXF
  Issue Type: Improvement
  Components: JAX-RS Security
Reporter: Sergey Beryozkin
Assignee: Sergey Beryozkin


Annotations like @ConfidentialClient, @Scopes("a", "b") should  be used in the 
combinations or separately, ex, this method can only be invoked if the client 
behind this access token is confidential, and/or this client has 'a' and 'b' 
scopes approved. OAuth2 filter can already so some fine-grained authorization 
(restrict to specific HTTP verbs or URI subsets) and the RS code can use 
OauthContext to manually check the scopes, the client type, etc, but the 
annotation-based AC would be quite handy too



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6597) Invalid Policy Exception on valid on WS-Policy

2015-11-04 Thread Bas Nossing (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CXF-6597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bas Nossing closed CXF-6597.


your feedback is very much appreciated. we shall file an issue with the creator 
of the WSDL

> Invalid Policy Exception on valid on WS-Policy
> --
>
> Key: CXF-6597
> URL: https://issues.apache.org/jira/browse/CXF-6597
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-WS Runtime
>Affects Versions: 3.0.6
> Environment: WildFly 8.2.1.Final
>Reporter: Bas Nossing
>Assignee: Colm O hEigeartaigh
>
> A recent bugreport (https://issues.apache.org/jira/browse/CXF-6473 to be 
> exact) was fixed in CXF version 3.0.6
> However, when we tried to update our WildFly to version 8.2.1 to incorporate 
> this bugfix we ran into a new issue: http://pastebin.com/ezewT9Mw
> It seems CXF version 3.0.6 introduces an issue with WS-Policy parsing that no 
> longer allows the following definition:
> {code:xml}
> 
>   
>   ...
>   
>   
>   
>   
>   
>   
>   
>   ...
>   
> 
> {code}
> (excerpt from WSDL http://pastebin.com/BSMais7F and accompanying XSD 
> http://pastebin.com/DRXc0Tfa)
> However, according to W3C (http://www.w3.org/Submission/WS-Policy/) it is 
> allowed to specify multiple key-transport-algorithms for a single policy.
> Removing two of the key-transport-algorithms (leaving one remaining 
> algorithm) from our definition makes the invalid policy exception disappear.
> For example removing Basic128Rsa15 and TripleDesRsa15 and leaving 
> Basic256Rsa15 will make CXF accept his WS-Policy as a valid one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6575) WS-A Action generation defect

2015-11-04 Thread Bas Nossing (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CXF-6575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bas Nossing closed CXF-6575.


thank you very much for the prompt fix! very nicely done.
how can i find out when this fix will be available in central maven repo?

> WS-A Action generation defect
> -
>
> Key: CXF-6575
> URL: https://issues.apache.org/jira/browse/CXF-6575
> Project: CXF
>  Issue Type: Bug
>  Components: WS-* Components
>Affects Versions: 3.0.6
> Environment: WildFly 8.1.0-Final
>Reporter: Bas Nossing
>Assignee: Akitoshi Yoshida
> Fix For: 3.1.3, 2.7.18, 3.0.7
>
>
> Some of our customers have complained about the ws-addressing "action" value 
> our system outputs in faults being incorrect.
> Service WSDL from which we generated JAX-WS classes:
> * AanleverService_WUS20V12.wsdl: http://pastebin.com/BSMais7F
> * digipoort-koppelvlak-1.2.xsd: http://pastebin.com/DRXc0Tfa
> Correct fault message:
> http://pastebin.com/GAKRshWE
> Incorrect fault message:
> http://pastebin.com/p7XjJKb9
> Expected  value:
> http://logius.nl/digipoort/wus/2.0/aanleverservice/1.2/AanleverService/aanleveren/Fault/
> Produced  value:
> http://logius.nl/digipoort/wus/2.0/aanleverservice/1.2/AanleverService_V1_2/aanleveren/Fault/aanleverFault



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6662) WS-A Action generation without explicit definition

2015-11-04 Thread Bas Nossing (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CXF-6662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bas Nossing closed CXF-6662.


> WS-A Action generation without explicit definition
> --
>
> Key: CXF-6662
> URL: https://issues.apache.org/jira/browse/CXF-6662
> Project: CXF
>  Issue Type: Bug
>  Components: WS-* Components
>Affects Versions: 2.7.17
> Environment: WildFly 8.1.0-Final patched with CXF-2.7.17
>Reporter: Bas Nossing
>Assignee: Daniel Kulp
>
> According to one of our clients the CXF WS-Adressing module is testing 
> erroneous values for the WS-Addressing "action" element.
> The error we're seeing in our serverlogs is the following:
> {noformat}
> WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-10) 
> Interceptor for 
> {http://logius.nl/digipoort/wus/2.0/aanleverservice/1.2/}AanleverService_V1_2#{http://logius.nl/digipoort/wus/2.0/aanleverservice/1.2/}aanleveren
>  has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault: 
> Action 
> http://logius.nl/digipoort/wus/2.0/aanleverservice/1.2/AanleverService_V1_2/aanleverenRequest
>  not supported
>   at 
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:515)
>  [cxf-rt-ws-addr.jar:2.7.17]
>   at 
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.handleMessage(MAPAggregatorImpl.java:143)
>  [cxf-rt-ws-addr.jar:2.7.17]
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
>  [cxf-api.jar:2.7.17]
>   at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>  [cxf-api.jar:2.7.17]
>   at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:249)
>  [cxf-rt-transports-http.jar:2.7.17]
>   at 
> org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97)
>   at 
> org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131)
>   at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:289)
>  [cxf-rt-transports-http.jar:2.7.17]
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:209)
>  [cxf-rt-transports-http.jar:2.7.17]
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) 
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
>   at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
>   at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) 
> [jbossws-spi.jar:2.3.1.Final]
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) 
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
>   at 
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>   at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
>  [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
>  [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
>  [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>  [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler

[jira] [Commented] (CXF-6662) WS-A Action generation without explicit definition

2015-11-04 Thread Bas Nossing (JIRA) 

[ 
https://issues.apache.org/jira/browse/CXF-6662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989145#comment-14989145
 ] 

Bas Nossing commented on CXF-6662:
--

Thanks you for looking further into this issue. I appreciate the very 
meticulous work!

> WS-A Action generation without explicit definition
> --
>
> Key: CXF-6662
> URL: https://issues.apache.org/jira/browse/CXF-6662
> Project: CXF
>  Issue Type: Bug
>  Components: WS-* Components
>Affects Versions: 2.7.17
> Environment: WildFly 8.1.0-Final patched with CXF-2.7.17
>Reporter: Bas Nossing
>Assignee: Daniel Kulp
>
> According to one of our clients the CXF WS-Adressing module is testing 
> erroneous values for the WS-Addressing "action" element.
> The error we're seeing in our serverlogs is the following:
> {noformat}
> WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-10) 
> Interceptor for 
> {http://logius.nl/digipoort/wus/2.0/aanleverservice/1.2/}AanleverService_V1_2#{http://logius.nl/digipoort/wus/2.0/aanleverservice/1.2/}aanleveren
>  has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault: 
> Action 
> http://logius.nl/digipoort/wus/2.0/aanleverservice/1.2/AanleverService_V1_2/aanleverenRequest
>  not supported
>   at 
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:515)
>  [cxf-rt-ws-addr.jar:2.7.17]
>   at 
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.handleMessage(MAPAggregatorImpl.java:143)
>  [cxf-rt-ws-addr.jar:2.7.17]
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
>  [cxf-api.jar:2.7.17]
>   at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>  [cxf-api.jar:2.7.17]
>   at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:249)
>  [cxf-rt-transports-http.jar:2.7.17]
>   at 
> org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97)
>   at 
> org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131)
>   at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:289)
>  [cxf-rt-transports-http.jar:2.7.17]
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:209)
>  [cxf-rt-transports-http.jar:2.7.17]
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) 
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
>   at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
>   at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) 
> [jbossws-spi.jar:2.3.1.Final]
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) 
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
>   at 
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>   at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
>  [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
>  [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
>  [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHan

[jira] [Comment Edited] (CXF-6662) WS-A Action generation without explicit definition

2015-11-04 Thread Bas Nossing (JIRA) 

[ 
https://issues.apache.org/jira/browse/CXF-6662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989145#comment-14989145
 ] 

Bas Nossing edited comment on CXF-6662 at 11/4/15 8:54 AM:
---

Thank you for looking further into this issue. I appreciate the very meticulous 
work!


was (Author: b.nossing):
Thanks you for looking further into this issue. I appreciate the very 
meticulous work!

> WS-A Action generation without explicit definition
> --
>
> Key: CXF-6662
> URL: https://issues.apache.org/jira/browse/CXF-6662
> Project: CXF
>  Issue Type: Bug
>  Components: WS-* Components
>Affects Versions: 2.7.17
> Environment: WildFly 8.1.0-Final patched with CXF-2.7.17
>Reporter: Bas Nossing
>Assignee: Daniel Kulp
>
> According to one of our clients the CXF WS-Adressing module is testing 
> erroneous values for the WS-Addressing "action" element.
> The error we're seeing in our serverlogs is the following:
> {noformat}
> WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-10) 
> Interceptor for 
> {http://logius.nl/digipoort/wus/2.0/aanleverservice/1.2/}AanleverService_V1_2#{http://logius.nl/digipoort/wus/2.0/aanleverservice/1.2/}aanleveren
>  has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault: 
> Action 
> http://logius.nl/digipoort/wus/2.0/aanleverservice/1.2/AanleverService_V1_2/aanleverenRequest
>  not supported
>   at 
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:515)
>  [cxf-rt-ws-addr.jar:2.7.17]
>   at 
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.handleMessage(MAPAggregatorImpl.java:143)
>  [cxf-rt-ws-addr.jar:2.7.17]
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
>  [cxf-api.jar:2.7.17]
>   at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>  [cxf-api.jar:2.7.17]
>   at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:249)
>  [cxf-rt-transports-http.jar:2.7.17]
>   at 
> org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97)
>   at 
> org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131)
>   at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:289)
>  [cxf-rt-transports-http.jar:2.7.17]
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:209)
>  [cxf-rt-transports-http.jar:2.7.17]
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) 
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
>   at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
>   at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) 
> [jbossws-spi.jar:2.3.1.Final]
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) 
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
>   at 
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>   at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
>  [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
>  [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
>  [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
>  [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>   at 
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
>  [un