[JBoss JIRA] (DROOLS-731) In a catch22 using a NOT constraint in rules shared by multiple facts
by Bill Tuminaro (JIRA)
Bill Tuminaro created DROOLS-731:
------------------------------------
Summary: In a catch22 using a NOT constraint in rules shared by multiple facts
Key: DROOLS-731
URL: https://issues.jboss.org/browse/DROOLS-731
Project: Drools
Issue Type: Feature Request
Components: core engine
Affects Versions: 6.1.0.Final, 6.0.1.Final
Environment: Custom application that completely wraps Drools Fusion written as an OSGI application hosted on Websphere Liberty profile.
Reporter: Bill Tuminaro
Assignee: Mario Fusco
I have a reproducer for these related issues.
We have encountered a couple of issues (Exceptions) when using a NOT constraint in rules that have facts associated with them when we call upgradeToVersion() or kSession.delete(). The catch22 is that one version of the NOT constraint avoids one Exception while causing another. Reproducing the issue requires 2 rules sharing the same NOT constraint. I have narrowed the issue(s) down to 2 very simple rules that use the org.drools.compiler.FactA class.
Here are the 2 rules used:
static final String ruleDrl = "package org.some.test\n" +
"import org.drools.compiler.FactA\n" +
"declare FactA\n" +
"@role(event)" +
"end\n" +
"rule \"R200_0\" when\n" +
// " $FactA : FactA ($FactA_field2 : field2 == 111002)\n" + // version A: using this version causes a NPE when calling ksession.delete()
" not FactA($FactA_field2 == 111002, this after $FactA)\n" +
" not FactA(field2 == 105742, this after $FactA)\n" + // Version B: using this version causes the IllegalArgumentException: Cannot remove a sink,
// when the list of sinks is null on the updateToVersion() call
"then\n" +
"end\n";
static final String ruleDrl2 = "package org.some.test\n" +
"import org.drools.compiler.FactA\n" +
"declare FactA\n" +
"@role(event)" +
"end\n" +
"rule \"R1437_0\" when\n" +
" $FactA : FactA ($FactA_field2 : field2 == 105742)\n" +
" not FactA($FactA_field2 == 105742, this after $FactA)\n" + // version A:
// " not FactA(field2 == 105742, this after $FactA)\n" + // Version B:
"then\n" +
"end\n";
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JGRP-1918) ConcurrentModificationException in Locking notification
by Paul Illingworth (JIRA)
Paul Illingworth created JGRP-1918:
--------------------------------------
Summary: ConcurrentModificationException in Locking notification
Key: JGRP-1918
URL: https://issues.jboss.org/browse/JGRP-1918
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.2
Environment: JUnit text running in Eclipse on Windows
Reporter: Paul Illingworth
Assignee: Bela Ban
I have code which unregisters a lock listener whilst a lock notification event is being fired leading to
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:926)
at java.util.HashMap$KeyIterator.next(HashMap.java:960)
at org.jgroups.protocols.Locking.notifyUnlocked(Locking.java:581)
at org.jgroups.protocols.Locking$ServerLock.setOwner(Locking.java:767)
at org.jgroups.protocols.Locking$ServerLock.handleRequest(Locking.java:655)
at org.jgroups.protocols.Locking.handleLockRequest(Locking.java:393)
at org.jgroups.protocols.Locking.up(Locking.java:226)
at org.jgroups.stack.Protocol.up(Protocol.java:412)
at org.jgroups.protocols.FORK.up(FORK.java:139)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:182)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
at org.jgroups.stack.Protocol.up(Protocol.java:420)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
at org.jgroups.protocols.UNICAST3.deliverBatch(UNICAST3.java:1087)
at org.jgroups.protocols.UNICAST3.removeAndDeliver(UNICAST3.java:886)
at org.jgroups.protocols.UNICAST3.handleDataReceivedFromSelf(UNICAST3.java:821)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:424)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:652)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
at org.jgroups.protocols.FD.up(FD.java:253)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
at org.jgroups.protocols.MERGE3.up(MERGE3.java:288)
at org.jgroups.protocols.Discovery.up(Discovery.java:291)
at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2842)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
at org.jgroups.protocols.TP$3.run(TP.java:1511)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
The org.jgroups.protocols.Locking#lock_listeners is simple a HashSet which gets iterated over, This needs to be synchronised is some way.
--
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 Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4393?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-4393:
---------------------------------
Assignee: Alessio Soldano (was: Jason Greene)
> 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] (JBMETA-385) Add overridable flag to servlet metadata
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/JBMETA-385?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski reassigned JBMETA-385:
-----------------------------------------
Assignee: Bartosz Baranowski (was: Jean-Frederic Clere)
> Add overridable flag to servlet metadata
> ----------------------------------------
>
> Key: JBMETA-385
> URL: https://issues.jboss.org/browse/JBMETA-385
> Project: JBoss Metadata
> Issue Type: Enhancement
> Components: web
> Affects Versions: 7.2.1.Final
> Reporter: James Livingston
> Assignee: Bartosz Baranowski
>
> To resolve https://bugzilla.redhat.com/show_bug.cgi?id=1094248, I believe we need an additional 'overridable' flag on the servlet metadata which indicates whether ServletContainerInitializers (and other code using servlet dynamic registration) should be allowed to override the servlet. Normally this is not allowed, however JBWeb's internal use of DefaultServlet to handle static resources should be.
> This only needs to go into 7, since the Undertow subsystem in Wildfly handles this quite differently, so does not need to pass a flag between components.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (DROOLS-729) Android Support
by Mark Proctor (JIRA)
[ https://issues.jboss.org/browse/DROOLS-729?page=com.atlassian.jira.plugin... ]
Mark Proctor commented on DROOLS-729:
-------------------------------------
Can you come onto irc and speak to Mario (mfusco). This will make it much easier to discuss all the related issues and for us to figure out how to integrate your changes.
http://drools.org/community/chat.html
> Android Support
> ---------------
>
> Key: DROOLS-729
> URL: https://issues.jboss.org/browse/DROOLS-729
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.0.1.Final
> Environment: Android
> Reporter: Mark Kedzierski
> Assignee: Mario Fusco
> Priority: Optional
> Labels: Android
>
> I've done some work porting Drools 6.0.1.Final to work on Android. My current effort uses Dex classloaders for all generated classes. Precompiled rule packages execute on Android with either java or mvel dialect.
> code:
> http://www.github.com/kedzie/drools-android
> http://www.github.com/kedzie/drools-android-sample
> Features:
> -Dex classloaders for all generated classes
> -Roboguice integration for injecting knowledge bases from precompiled packages
> -Maven plugin which pre-compiles rule packages
> Issues:
> -Unit tests don't work because it always uses dex classloader, which doesn't work on a desktop system
> -Haven't tested drools-compiler on android platform
> I am wondering how to move forward and contribute this code. I think it would be ideal if the same codebase worked on both desktop and android platforms. Otherwise it would need to be a seperate fork. Also how to manage unit testing in the Android version. Any thoughts welcome.
--
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 updated WFLY-4393:
------------------------------------
Attachment: handler_header_chain.zip
> 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: Jason Greene
> 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-4362) Web container (undertow) isn't able to compile JSPs containing JDK 8 specific code (lambda expressions)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4362?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4362:
-----------------------------------------------
Radim Hatlapatka <rhatlapa(a)redhat.com> changed the Status of [bug 1193553|https://bugzilla.redhat.com/show_bug.cgi?id=1193553] from ON_QA to VERIFIED
> Web container (undertow) isn't able to compile JSPs containing JDK 8 specific code (lambda expressions)
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4362
> URL: https://issues.jboss.org/browse/WFLY-4362
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.0.Alpha1
> Environment: jdk1.8
> Reporter: Radim Hatlapatka
> Assignee: Tomaz Cerar
> Priority: Critical
> Attachments: lambda-expression-test.war
>
>
> Accessing JSP with JDK8 specific code (namely lambda expressions) fails due compilation error [1].
> It didn't help setting
> {code}
> <jsp-config source-vm="1.8" target-vm="1.8"/> in <servlet-container name="default">
> {code}
> It is caused due ecj-4.3.1.jar supports only JDKs till 1.7.
> [1]
> {noformat}
> 09:58:44,480 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /lambda-expression-test/jsp-with-lambdas.jsp: org.apache.jasper.JasperException: JBWEB004062: Unable to compile class for JSP:
> JBWEB004060: An error occurred at line: 10 in the jsp file: /jsp-with-lambdas.jsp
> n cannot be resolved to a variable
> 7: // System.out.println(answerToEverything);
> 8:
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> JBWEB004060: An error occurred at line: 10 in the jsp file: /jsp-with-lambdas.jsp
> Syntax error on token "-", -- expected
> 7: // System.out.println(answerToEverything);
> 8:
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> JBWEB004060: An error occurred at line: 10 in the jsp file: /jsp-with-lambdas.jsp
> n cannot be resolved to a variable
> 7: // System.out.println(answerToEverything);
> 8:
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> JBWEB004060: An error occurred at line: 12 in the jsp file: /jsp-with-lambdas.jsp
> n cannot be resolved to a variable
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> 14: %>
> 15: </body>
> JBWEB004060: An error occurred at line: 12 in the jsp file: /jsp-with-lambdas.jsp
> Syntax error on token "-", -- expected
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> 14: %>
> 15: </body>
> JBWEB004060: An error occurred at line: 12 in the jsp file: /jsp-with-lambdas.jsp
> n cannot be resolved to a variable
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> 14: %>
> 15: </body>
> JBWEB004211: Stacktrace:
> at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:85) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:69) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:451) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:361) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:339) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:604) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:309) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-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.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> 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.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> 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.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]
> {noformat}
--
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 updated WFLY-4393:
------------------------------------
Description:
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.
> 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: Jason Greene
>
> 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