[JBoss JIRA] (WFLY-8080) ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-8080:
------------------------------------
Summary: ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'
Key: WFLY-8080
URL: https://issues.jboss.org/browse/WFLY-8080
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.0.0.Final
Environment: Apache HTTP server 2.2.22 with mod_jk 1.2.37
Reporter: river shen
Assignee: Stuart Douglas
When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior:
if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1.
It only happens when the request is routed by apache web server through ajp; it does not happen if the client talks to wildfly directly through its 8080 http port.
We have attached a minimal web application that reproduce this issue.
Also attached is the standalone.xml and the apache configuration file.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2288) Indexed adds for override models of ordered child types does not work
by Paul Ferraro (JIRA)
Paul Ferraro created WFCORE-2288:
------------------------------------
Summary: Indexed adds for override models of ordered child types does not work
Key: WFCORE-2288
URL: https://issues.jboss.org/browse/WFCORE-2288
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 3.0.0.Alpha24
Reporter: Paul Ferraro
Assignee: Brian Stansberry
This is due to the following logic in AbstractAddStepHandler:
{noformat}
protected Resource createResource(final OperationContext context, final ModelNode operation) {
ImmutableManagementResourceRegistration registration = context.getResourceRegistration();
if (registration != null) {
Set<String> orderedChildTypes = registration.getOrderedChildTypes();
boolean orderedChildResource = registration.isOrderedChildResource();
if (orderedChildResource || orderedChildTypes.size() > 0) {
return new OrderedResourceCreator(orderedChildResource, orderedChildTypes).createResource(context, operation);
}
}
return createResource(context);
}
{noformat}
Override models fail to use the OrderedResourceCreator because registration.isOrderedChildResource() returns false.
There are a number of ways to handle this:
1. Allow override model registration to indicate that they are ordered. Currently, the MRR implementation throws an exception if an override model registration tries to specify that it is ordered, and the corresponding wildcard registration is ordered.
2. Auto-set override model registrations to be ordered if the corresponding wildcard registration is ordered.
3. In AbstractAddStepHandler, when determining whether or not to use an OrderedResourceCreator, test if either registration.isOrderedChildResource() is true *or*, if a wildcard registration exists, check if its registration.isOrderedChildResource() is true.
Of these three options, #3 is probably the easiest, and most sensible solution.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1436) Unable to create runtime for the attached DMN model
by Mélanie Gauthier (JIRA)
Mélanie Gauthier created DROOLS-1436:
----------------------------------------
Summary: Unable to create runtime for the attached DMN model
Key: DROOLS-1436
URL: https://issues.jboss.org/browse/DROOLS-1436
Project: Drools
Issue Type: Bug
Components: dmn engine
Reporter: Mélanie Gauthier
Assignee: Edson Tirelli
Attachments: Get Viable Loan Products.dmn
When trying to load that model, the following errors is logged:
java.lang.IllegalStateException: [Message [id=1, kieBase=defaultKieBase, level=ERROR, path=trisotech/Get_Viable_Loan_Products.dmn, line=-1, column=0
text=Unable to compile DMN model for the resource]]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-6671) ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'
by Aaron Ogburn (JIRA)
[ https://issues.jboss.org/browse/WFLY-6671?page=com.atlassian.jira.plugin.... ]
Aaron Ogburn reopened WFLY-6671:
--------------------------------
I reproduced this with EAP 7.0.4 + JBCS httpd/mod_jk as well. mod_proxy_ajp works. Inspecting tcp dumps, I see a potential difference to explain this. The last empty body message sent by mod_jk is the following:
12 34 00 00
So it just says no message length, but undertow doesn't seem to interpret this as a signal to end its request body read.
Compared to mod_proxy_ajp, it sends the following for the final body message:
12 34 00 02 00 00
So mod_proxy_ajp seems to say it has a body length of 2 bytes (which are empty) and undertow ends its request body read after seeing this. Does undertow need a change to recognize mod_jk's end body message too?
> ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-6671
> URL: https://issues.jboss.org/browse/WFLY-6671
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: Apache HTTP server 2.2.22 with mod_jk 1.2.37
> Reporter: river shen
> Assignee: Stuart Douglas
> Attachments: service-1.0-SNAPSHOT.war, src.zip, stacks.txt, standalone.xml, workers.properties
>
>
> When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior:
> if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1.
> It only happens when the request is routed by apache web server through ajp; it does not happen if the client talks to wildfly directly through its 8080 http port.
> We have attached a minimal web application that reproduce this issue.
> Also attached is the standalone.xml and the apache configuration file.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-902) Deployment fails when unreachable LDAP is used for Elytron LDAP authentication and ldap-realm.direct-verification=true
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-902?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-902:
---------------------------
Fix Version/s: 1.1.0.Beta24
> Deployment fails when unreachable LDAP is used for Elytron LDAP authentication and ldap-realm.direct-verification=true
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-902
> URL: https://issues.jboss.org/browse/ELY-902
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta21
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 1.1.0.Beta24
>
>
> In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses ldap-realm with direct-verification=true and which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.
> We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.
> Deployment fails with following exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:84)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
> ... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:416)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:413)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:356)
> at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:409)
> at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:209)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> ... 8 more
> ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "print-roles.war")]) - failure description: {
> "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./print-roles" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"]
> }
> {code}
> It is similar issue as ELY-668 - the difference is that {{direct-verification=true}} is configured in current issue.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2287) DeploymentScanner failure during reconfiguring using embed-server
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2287?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-8079 to WFCORE-2287:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-2287 (was: WFLY-8079)
Component/s: Domain Management
Security
(was: Domain Management)
(was: Security)
> DeploymentScanner failure during reconfiguring using embed-server
> -----------------------------------------------------------------
>
> Key: WFCORE-2287
> URL: https://issues.jboss.org/browse/WFCORE-2287
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Josef Cacek
> Assignee: Brian Stansberry
> Priority: Critical
>
> Running a JBoss CLI script with embed-server led to DeploymentScanner (intermittent) failure:
> {code}
> 2017-02-10 21:16:00,591 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /home/kwart/projects/wildfly/wildfly/testsuite/integration/smoke/target/jbossas/standalone/deployments threw Exception: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> at org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:59)
> at org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:39)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:223)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:711)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:701)
> at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations$ControllerClient$1.lambda$execute$0(DefaultDeploymentOperations.java:158)
> at org.jboss.as.controller.access.InVmAccess.runInVm(InVmAccess.java:85)
> at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations$ControllerClient$1.execute(DefaultDeploymentOperations.java:158)
> at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.execute(DefaultDeploymentOperations.java:137)
> at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.getDeploymentsStatus(DefaultDeploymentOperations.java:81)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1685)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1634)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.forcedUndeployScan(FileSystemDeploymentService.java:519)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$UndeployScanRunnable.run(FileSystemDeploymentService.java:770)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> *Background:*
> We use {{enable-elytron.cli}} script to reconfigure server profiles (default and full) in the testsuite to run with Elytron provided security.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8079) DeploymentScanner failure during reconfiguring using embed-server
by Josef Cacek (JIRA)
Josef Cacek created WFLY-8079:
---------------------------------
Summary: DeploymentScanner failure during reconfiguring using embed-server
Key: WFLY-8079
URL: https://issues.jboss.org/browse/WFLY-8079
Project: WildFly
Issue Type: Bug
Components: Domain Management, Security
Reporter: Josef Cacek
Assignee: Brian Stansberry
Priority: Critical
Running a JBoss CLI script with embed-server led to DeploymentScanner (intermittent) failure:
{code}
2017-02-10 21:16:00,591 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /home/kwart/projects/wildfly/wildfly/testsuite/integration/smoke/target/jbossas/standalone/deployments threw Exception: java.lang.IllegalStateException
at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
at org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:59)
at org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:39)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:223)
at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:711)
at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:701)
at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations$ControllerClient$1.lambda$execute$0(DefaultDeploymentOperations.java:158)
at org.jboss.as.controller.access.InVmAccess.runInVm(InVmAccess.java:85)
at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations$ControllerClient$1.execute(DefaultDeploymentOperations.java:158)
at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.execute(DefaultDeploymentOperations.java:137)
at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.getDeploymentsStatus(DefaultDeploymentOperations.java:81)
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1685)
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1634)
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.forcedUndeployScan(FileSystemDeploymentService.java:519)
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$UndeployScanRunnable.run(FileSystemDeploymentService.java:770)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
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)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
*Background:*
We use {{enable-elytron.cli}} script to reconfigure server profiles (default and full) in the testsuite to run with Elytron provided security.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2286) GenericSubsystemDescribeHandler generates duplicates operations for override models
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2286?page=com.atlassian.jira.plugi... ]
Paul Ferraro reassigned WFCORE-2286:
------------------------------------
Assignee: Brian Stansberry (was: Paul Ferraro)
> GenericSubsystemDescribeHandler generates duplicates operations for override models
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-2286
> URL: https://issues.jboss.org/browse/WFCORE-2286
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha24
> Reporter: Paul Ferraro
> Assignee: Brian Stansberry
>
> Currently, GenericSubsystemDescribeHandler relies on ImmutableManagementResourceRegistration.getChildAddresses(...) to find child resources. When processing a wildcard address, all resource children are matched. Thus any non-wildcard paths returned by getChildAddresses(...) for the same child type will end up being described twice. Additionally, child order needs to be preserved, even in the presence of override models.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2286) GenericSubsystemDescribeHandler generates duplicates operations for override models
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2286?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFCORE-2286:
---------------------------------
Description: Currently, GenericSubsystemDescribeHandler relies on ImmutableManagementResourceRegistration.getChildAddresses(...) to find child resources. When processing a wildcard address, all resource children are matched. Thus any non-wildcard paths returned by getChildAddresses(...) for the same child type will end up being described twice. Additionally, child order needs to be preserved, even in the presence of override models. (was: Currently, GenericSubsystemDescribeHandler relies on ImmutableManagementResourceRegistration.getChildAddresses(...) to find child resources. When processing a wildcard address, all resource children are matched. Thus any non-wildcard paths returned by getChildAddresses(...) for the same child type will end up being described twice.)
> GenericSubsystemDescribeHandler generates duplicates operations for override models
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-2286
> URL: https://issues.jboss.org/browse/WFCORE-2286
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha24
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Currently, GenericSubsystemDescribeHandler relies on ImmutableManagementResourceRegistration.getChildAddresses(...) to find child resources. When processing a wildcard address, all resource children are matched. Thus any non-wildcard paths returned by getChildAddresses(...) for the same child type will end up being described twice. Additionally, child order needs to be preserved, even in the presence of override models.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-972) Provide a way to correlate HTTP management requests
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-972?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-972:
---------------------------------------
Assignee: Brian Stansberry (was: Heiko Braun)
> Provide a way to correlate HTTP management requests
> ---------------------------------------------------
>
> Key: WFCORE-972
> URL: https://issues.jboss.org/browse/WFCORE-972
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Beta1
>
>
> {noformat}
> public class CorrelationHandler implements HttpHandler {
> private static final HttpString HEADER = new HttpString("X-CORR-ID");
> private final HttpHandler next;
> public CorrelationHandler(HttpHandler next) {
> this.next = next;
> }
> @Override
> public void handleRequest(HttpServerExchange exchange) throws Exception {
> String corr = exchange.getRequestHeaders().getFirst(HEADER);
> if(corr != null) {
> exchange.getResponseHeaders().put(HEADER, corr);
> }
> next.handleRequest(exchange);
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months