[JBoss JIRA] (WFLY-4393) Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers
by Takashi Nishigaya (JIRA)
[ https://issues.jboss.org/browse/WFLY-4393?page=com.atlassian.jira.plugin.... ]
Takashi Nishigaya edited comment on WFLY-4393 at 3/4/15 12:14 AM:
------------------------------------------------------------------
I found the following implementation in SOAPMessageContextImpl.java.
rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/soap/SOAPMessageContextImpl.java:
{noformat}
public Object get(Object key) {
Object o = super.get(key);
if (MessageContext.HTTP_RESPONSE_HEADERS.equals(key)
|| MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
Map<?, ?> mp = (Map<?, ?>)o;
if (mp != null) {
if (mp.isEmpty()) {
return null;
}
if (!isRequestor() && isOutbound() && MessageContext.HTTP_RESPONSE_HEADERS.equals(key)) {
return null;
}
if (isRequestor() && isOutbound() && MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
return null;
}
{noformat}
It results in HTTP_REQUEST_HEADERS is always null, when the handler chain is in client-side outbound processing.
JSR224 spec does not apparently say when it is available. But I think it is not necessary to hide it, for compatibility with the Java SE default implementations.
was (Author: nishigaya):
I found the following implementation in SOAPMessageContextImpl.java.
rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/soap/SOAPMessageContextImpl.java:
public Object get(Object key) {
Object o = super.get(key);
if (MessageContext.HTTP_RESPONSE_HEADERS.equals(key)
|| MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
Map<?, ?> mp = (Map<?, ?>)o;
if (mp != null) {
if (mp.isEmpty()) {
return null;
}
if (!isRequestor() && isOutbound() && MessageContext.HTTP_RESPONSE_HEADERS.equals(key)) {
return null;
}
if (isRequestor() && isOutbound() && MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
return null;
}
It results in HTTP_REQUEST_HEADERS is always null, when the handler chain is in client-side outbound processing.
JSR224 spec does not apparently say when it is available. But I think it is not necessary to hide it, for compatibility with the Java SE default implementations.
> Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-4393
> URL: https://issues.jboss.org/browse/WFLY-4393
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.2.0.Final
> Reporter: Takashi Nishigaya
> Assignee: Alessio Soldano
> Attachments: handler_header_chain.zip
>
>
> CXF runtime does NOT propagate JAX-WS standard context value MessageContext.HTTP_REQUEST_HEADERS to the subsequent client-side SOAP handlers. For instance,
> 1. The first client handler puts the newly created HTTP request header map that contains the custom header 'foo' in the message context.
> 2. The second client handler can not refer to the custom header 'foo' added in the step 1. The HTTP request header map in the message context is null.
> The weird thing is that the custom header added in the step 1 is correctly received by the server-side web services.
> The both of Java SE default JAX-WS implementations and GlassFish correctly share HTTP_REQUEST_HEADERS map between handlers.
> Please check the attached test case and compare the two test case. The method testHandlerChainOnServer() tests the case that the client is running on the container. On the other hand, testHandlerChainOnStandalone() tests the standalone client case.
> In order to reproduce the issue:
> $ mvm clean test -P wildly-managed (or -P wildly-remote)
> Additionally, this behavior is the same in EAP 6.3.3.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-4393) Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers
by Takashi Nishigaya (JIRA)
[ https://issues.jboss.org/browse/WFLY-4393?page=com.atlassian.jira.plugin.... ]
Takashi Nishigaya commented on WFLY-4393:
-----------------------------------------
I found the following implementation in SOAPMessageContextImpl.java.
rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/soap/SOAPMessageContextImpl.java:
public Object get(Object key) {
Object o = super.get(key);
if (MessageContext.HTTP_RESPONSE_HEADERS.equals(key)
|| MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
Map<?, ?> mp = (Map<?, ?>)o;
if (mp != null) {
if (mp.isEmpty()) {
return null;
}
if (!isRequestor() && isOutbound() && MessageContext.HTTP_RESPONSE_HEADERS.equals(key)) {
return null;
}
if (isRequestor() && isOutbound() && MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
return null;
}
It results in HTTP_REQUEST_HEADERS is always null, when the handler chain is in client-side outbound processing.
JSR224 spec does not apparently say when it is available. But I think it is not necessary to hide it, for compatibility with the Java SE default implementations.
> Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-4393
> URL: https://issues.jboss.org/browse/WFLY-4393
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.2.0.Final
> Reporter: Takashi Nishigaya
> Assignee: Alessio Soldano
> Attachments: handler_header_chain.zip
>
>
> CXF runtime does NOT propagate JAX-WS standard context value MessageContext.HTTP_REQUEST_HEADERS to the subsequent client-side SOAP handlers. For instance,
> 1. The first client handler puts the newly created HTTP request header map that contains the custom header 'foo' in the message context.
> 2. The second client handler can not refer to the custom header 'foo' added in the step 1. The HTTP request header map in the message context is null.
> The weird thing is that the custom header added in the step 1 is correctly received by the server-side web services.
> The both of Java SE default JAX-WS implementations and GlassFish correctly share HTTP_REQUEST_HEADERS map between handlers.
> Please check the attached test case and compare the two test case. The method testHandlerChainOnServer() tests the case that the client is running on the container. On the other hand, testHandlerChainOnStandalone() tests the standalone client case.
> In order to reproduce the issue:
> $ mvm clean test -P wildly-managed (or -P wildly-remote)
> Additionally, this behavior is the same in EAP 6.3.3.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-4402) Fails to load JAX-RS Application class if deployment runtime name is changed
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4402?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4402.
----------------------------------
Resolution: Cannot Reproduce Bug
I just tested this against upstream and I cannot reproduce it.
> Fails to load JAX-RS Application class if deployment runtime name is changed
> ----------------------------------------------------------------------------
>
> Key: WFLY-4402
> URL: https://issues.jboss.org/browse/WFLY-4402
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final
> Environment: Oracle JDK 1.8.0_25
> Reporter: Abhijit Sarkar
> Assignee: David Lloyd
> Priority: Critical
> Attachments: availability-service-0.0.1-SNAPSHOT.war
>
>
> If the runtime name is modified during deployment, it fails with a {{ClassNotFoundException}}. The runtime name determines the context root so in most practical cases, it'd be different from the archive name. Seems related to WFLY-1521 which was closed.
> {code}
> wildfly-server-8.2.0.Final.jar:8.2.0.Final]
> ... 5 more
> Caused by: java.lang.ClassNotFoundException: name.abhijitsarkar.microservices.availability.AvailabilityApp from [Module "deployment.availability-service:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBJCA-1251) Exclude decrementer policy for CRI pools
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-1251:
--------------------------------------
Summary: Exclude decrementer policy for CRI pools
Key: JBJCA-1251
URL: https://issues.jboss.org/browse/JBJCA-1251
Project: IronJacamar
Issue Type: Task
Components: Core
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Fix For: 1.2.3.Final
Otherwise there could be configurations where the pools never would empty
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-4331) EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-4331?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski commented on WFLY-4331:
--------------------------------------
Yeah I look at this part of spec to and I'm a bit confused as TCK returns non serializable object in EJB invocation.
Is it possible that arguments passed as parameters are treated differently that returned values?
> EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-4331
> URL: https://issues.jboss.org/browse/WFLY-4331
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: 9.0.0.Beta1
>
>
> When invoking EJB asynchronous in different deployments and returning a POJO object, which will be retrieved using future.get, we have ClassCastException error.
> {code}
> 12:53:50,147 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /testejb-web/async: java.lang.ClassCastException: rh.test.ReturnObject cannot be cast to rh.test.ReturnObject
> at rh.test.AsyncServlet.doGet(AsyncServlet.java:29) [classes:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.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.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:259) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:246) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:75) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:165) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:737) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-4331) EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-4331?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski updated WFLY-4331:
---------------------------------
Comment: was deleted
(was: Yeah I look at this part of spec to and I'm a bit confused as TCK returns non serializable object in EJB invocation.
Is it possible that arguments passed as parameters are treated differently that returned values?)
> EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-4331
> URL: https://issues.jboss.org/browse/WFLY-4331
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: 9.0.0.Beta1
>
>
> When invoking EJB asynchronous in different deployments and returning a POJO object, which will be retrieved using future.get, we have ClassCastException error.
> {code}
> 12:53:50,147 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /testejb-web/async: java.lang.ClassCastException: rh.test.ReturnObject cannot be cast to rh.test.ReturnObject
> at rh.test.AsyncServlet.doGet(AsyncServlet.java:29) [classes:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.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.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:259) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:246) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:75) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:165) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:737) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months