[JBoss JIRA] (WFLY-13397) MP HeaderPropagation does not propagate headers
by Moulali Shikalwadi (Jira)
[ https://issues.redhat.com/browse/WFLY-13397?page=com.atlassian.jira.plugi... ]
Moulali Shikalwadi reassigned WFLY-13397:
-----------------------------------------
Assignee: Moulali Shikalwadi
> MP HeaderPropagation does not propagate headers
> -----------------------------------------------
>
> Key: WFLY-13397
> URL: https://issues.redhat.com/browse/WFLY-13397
> Project: WildFly
> Issue Type: Bug
> Components: MP REST Client
> Affects Versions: 19.0.0.Final
> Reporter: Thimo König
> Assignee: Moulali Shikalwadi
> Priority: Major
> Attachments: mp-headerpropagation-1.0.0-SNAPSHOT-sources.jar, mp-headerpropagation-1.0.0-SNAPSHOT.war, openliberty_response.json, wildfly_response.json
>
>
> When calling a JAX-RS Resource from another JAX-RS Resource using the MP RestClient the propagation of headers does not work. I have created a sample app which is available on github https://github.com/koenigt/headerpropagation and attached [^mp-headerpropagation-1.0.0-SNAPSHOT.war] to this report aswell.
> Deploy the sample app and use CURL like:
> {code}
> curl -i -H "Accept: application/json" -H "Header2Propagate: PropagatedValue" http://localhost:8080/mp-hp/api/client {code}
> The expected result should be:
> {code:JSON}
> {
> "Name": "ClientResource",
> "org.eclipse.microprofile.rest.client.propagateHeaders": "Authorization,Accept-Language,Header2Propagate",
> "IncomingRequestHeaders": {
> "Accept": "[*/*]",
> "accept-encoding": "[gzip, deflate, br]",
> "Cache-Control": "[no-cache]",
> "connection": "[keep-alive]",
> "Content-Type": "[null]",
> "Header2Propagate": "[PropagatedValue]",
> "Host": "[localhost:9080]",
> "Postman-Token": "[8105e2ef-9b5f-4b3f-a7a9-cea73d51efee]",
> "User-Agent": "[PostmanRuntime/7.24.0]"
> },
> "ServerResponse": {
> "Name": "ServerResource",
> "IncomingRequestHeaders": {
> "Accept": "[application/json]",
> "Cache-Control": "[no-cache]",
> "connection": "[keep-alive]",
> "content-type": "[application/json]",
> "Header2Propagate": "[PropagatedValue]",
> "Host": "[localhost:9080]",
> "MyClientHeader": "[newHeaderValue]",
> "Pragma": "[no-cache]",
> "User-Agent": "[Apache-CXF/3.3.3-SNAPSHOT]"
> }
> }
> }
> {code}
> but since the header is not propagated you are getting only this:
> {code:JSON}
> {
> "Name": "ClientResource",
> "org.eclipse.microprofile.rest.client.propagateHeaders": "Authorization,Accept-Language,Header2Propagate",
> "IncomingRequestHeaders": {
> "Accept": "[*/*]",
> "Accept-Encoding": "[gzip, deflate, br]",
> "Cache-Control": "[no-cache]",
> "Connection": "[keep-alive]",
> "Header2Propagate": "[PropagatedValue]",
> "Host": "[localhost:8080]",
> "Postman-Token": "[6e36736f-3b55-4f34-9f39-063dbd4f4e8f]",
> "User-Agent": "[PostmanRuntime/7.24.0]"
> },
> "ServerResponse": {
> "Name": "ServerResource",
> "IncomingRequestHeaders": {
> "Accept": "[application/json]",
> "Connection": "[Keep-Alive]",
> "Host": "[localhost:8080]",
> "User-Agent": "[Apache-HttpClient/4.5.11 (Java/12)]",
> "uber-trace-id": "[a0d9d0ac4c54614%3Ac82190f35d41f958%3Aa0d9d0ac4c54614%3A1]"
> }
> }
> }
> {code}
> This issue has already been discussed on https://groups.google.com/forum/#!topic/wildfly/QOx3AfrXAMc and Rebecca Searls (rseals(a)redhat.com) ask me to file this bug report
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (SWSQE-1140) Find better solution for fbr-test2 VM
by Filip Brychta (Jira)
Filip Brychta created SWSQE-1140:
------------------------------------
Summary: Find better solution for fbr-test2 VM
Key: SWSQE-1140
URL: https://issues.redhat.com/browse/SWSQE-1140
Project: Kiali QE
Issue Type: QE Task
Reporter: Filip Brychta
Assignee: Filip Brychta
fbr-test2 VM in PSI OpenStack is used to upload RHCOS images. It's static and consuming resources. Maybe we could create/destroy it dynamically or at least use less memory.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13262) Enforcer reports conflicts for io.undertow:undertow-servlet
by Szymon Klepacz (Jira)
[ https://issues.redhat.com/browse/WFLY-13262?page=com.atlassian.jira.plugi... ]
Szymon Klepacz commented on WFLY-13262:
---------------------------------------
Issue is not resolved in 19.1.0. How about plans for 20?
> Enforcer reports conflicts for io.undertow:undertow-servlet
> -----------------------------------------------------------
>
> Key: WFLY-13262
> URL: https://issues.redhat.com/browse/WFLY-13262
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Web (Undertow)
> Affects Versions: 19.0.0.Final
> Reporter: Szymon Klepacz
> Assignee: Flavia Rainone
> Priority: Major
>
> Enforcer conflict for MP health:
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-microprofile-health-smallrye</artifactId>
> <version>19.0.0.Final</version>
> </dependency>
> +-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> +-org.wildfly:wildfly-microprofile-health-smallrye:19.0.0.Final
> +-org.wildfly:wildfly-undertow:19.0.0.Final
> +-io.undertow:undertow-servlet:2.0.30.Final
> and
> +-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> +-org.wildfly:wildfly-microprofile-health-smallrye:19.0.0.Final
> +-org.wildfly:wildfly-undertow:19.0.0.Final
> +-io.undertow:undertow-websockets-jsr:2.0.30.Final
> +-io.undertow:undertow-servlet:2.0.30.Final
> and
> +-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> +-org.wildfly:wildfly-microprofile-health-smallrye:19.0.0.Final
> +-org.wildfly:wildfly-undertow:19.0.0.Final
> +-io.undertow.jastow:jastow:2.0.8.Final
> +-io.undertow:undertow-servlet:1.2.6.Final
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5106) Local/Internal Maven Repos can not be accessed
by Steve Davidson (Jira)
[ https://issues.redhat.com/browse/DROOLS-5106?page=com.atlassian.jira.plug... ]
Steve Davidson commented on DROOLS-5106:
----------------------------------------
Do you have an artifact for this in your local repo? I'm also using a proxied repo with artifact, and running into the same issue. Note that the artifact in question is NOT in the main repos -- and probably won't be. It will only be in local repos.
> Local/Internal Maven Repos can not be accessed
> ----------------------------------------------
>
> Key: DROOLS-5106
> URL: https://issues.redhat.com/browse/DROOLS-5106
> Project: Drools
> Issue Type: Bug
> Components: Artifact Repository
> Affects Versions: 7.33.0.Final
> Reporter: Steve Davidson
> Assignee: Luca Molteni
> Priority: Major
> Labels: Drools, drools-compiler, maven
> Attachments: settings.xml
>
>
> Attempting to use an internal Nexus Repository, unable to load Drools KIE Modules using Maven. This works with 7.29.Final. Changing to 7.33.Final fails with the following stack trace;
> {code:java}
> WARNING: Environment variable M2_HOME is not set
> Feb 24, 2020 5:12:30 PM org.kie.server.services.impl.KieServerImpl createContainer
> SEVERE: Error creating container 'JUnit Test: kie-server' for module 'com.j2eeguys.demo:KieIssueDemo:0.1.0-SNAPSHOT'
> java.lang.RuntimeException: Cannot find KieModule: com.j2eeguys.demo:KieIssueDemo:0.1.0-SNAPSHOT
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:186)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:176)
> at org.kie.server.services.impl.KieServerImpl.createContainer(KieServerImpl.java:281)
> at org.kie.server.remote.rest.common.resource.KieServerRestImpl.createContainer(KieServerRestImpl.java:157)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:443)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:233)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:139)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:142)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:219)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.eclipse.jetty.servlet.ServletHolder$NotAsyncServlet.service(ServletHolder.java:1401)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:760)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1617)
> at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
> at org.kie.server.services.impl.security.web.CaptureHttpRequestFilter.doFilter(CaptureHttpRequestFilter.java:42)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:501)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1592)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1296)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1562)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1211)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:386)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:562)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:378)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:270)
> at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:388)
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
> at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-255) jboss.server.base.dir, jboss.server.config.dir and jboss.server.log.dir should also be allowed to be set as a system-property resource or overridden via JAVA_OPTS or the launch-command.
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-255?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-255:
--------------------------------------
One workaround I did not think about until just now. If you change the {{directory-grouping}} to {{by-type}} and then override the {{jboss.domain.log.dir}} that at least puts all the logs into the same main directory.
{code}
$JBOSS_HOME/bin/jboss-cli.sh -commands="embed-host-controller,/host=master:write-attribute(name=directory-grouping, value=by-type),stop-embedded-host-controller"
$JBOSS_HOME/bin/domain.sh -Djboss.domain.log.dir=/var/log/
{code}
That results in something like:
{code}
jperkins@localhost ~/tmp/logs $ tree
.
├── audit.log
├── host-controller.log
├── process-controller.log
└── servers
├── server-one
│ ├── audit.log
│ └── server.log
└── server-two
├── audit.log
└── server.log
{code}
> jboss.server.base.dir, jboss.server.config.dir and jboss.server.log.dir should also be allowed to be set as a system-property resource or overridden via JAVA_OPTS or the launch-command.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-255
> URL: https://issues.redhat.com/browse/WFCORE-255
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
> Labels: domain-mode, downstream_dependency
>
> The three properties {{jboss.server.base.dir}}, {{jboss.server.config.dir}} and {{jboss.server.log.dir}} are allowed to be overridden for servers. For a domain server, these values need to be allowed to be set as a {{boot-time=true}} system property.
> These properties should also be allowed to be set as a system-property resource or overridden via {{JAVA_OPTS}} or the {{launch-command}}.
> The {{add}}, {{write-attribute}} and {{remove}} operations should not modify the runtime, but should modify the model. It's debatable whether the server should be put in a {{restart-required}} state. Currently similar resources do _not_ set the server state to {{restart-required}}. For now we should stick with the same state.
> {code}
> [domain@localhost:9999 /] /host=master/system-property=jboss.server.log.dir:add(boot-time=true,value="/var/log")
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
> "rolled-back" => true,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {
> "server-one" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "JBAS015845: System property jboss.server.log.dir cannot be set via the xml configuration file or from a management client; it's value must be known at initial process start so it can only set from the commmand line",
>
> "rolled-back" => true
> }},
> "server-two" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "JBAS015845: System property jboss.server.log.dir cannot be set via the xml configuration file or from a management client; it's value must be known at initial process start so it can only set from the commmand line",
> "rolled-back" => true
> }}
> }}}}
> }
> {code}
> These properties should also be allowed to be set in the {{/host=\*/server-config=\*/jvm=\*/}} resource on the {{jvm-options}} and likely {{launch-command}} attributes.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-10942) IIOPTimeoutTestCase fails intermittently
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-10942?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-10942:
-----------------------------------
This test, along with many other tests, uses a singleton ejb {{TransactionCheckerSingleton}} to record the bean invocation activities, such as number of rollbacks, beforeCompletion, afterCompletion calls.
{{TransactionCheckerSingleton}} is updated by test ejbs, and accessed by test client from different threads for verification purpose. When a test client reads stale cached values (not the expected result), the test will fail.
> IIOPTimeoutTestCase fails intermittently
> ----------------------------------------
>
> Key: WFLY-10942
> URL: https://issues.redhat.com/browse/WFLY-10942
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 14.0.0.Beta2
> Reporter: Tomasz Adamski
> Assignee: Cheng Fang
> Priority: Major
>
> {code}
> java.lang.AssertionError: Synchronization after completion should be called expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful(IIOPTimeoutTestCase.java:175)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-10942) IIOPTimeoutTestCase fails intermittently
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-10942?page=com.atlassian.jira.plugi... ]
Cheng Fang reassigned WFLY-10942:
---------------------------------
Assignee: Cheng Fang (was: Tomasz Adamski)
> IIOPTimeoutTestCase fails intermittently
> ----------------------------------------
>
> Key: WFLY-10942
> URL: https://issues.redhat.com/browse/WFLY-10942
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 14.0.0.Beta2
> Reporter: Tomasz Adamski
> Assignee: Cheng Fang
> Priority: Major
>
> {code}
> java.lang.AssertionError: Synchronization after completion should be called expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful(IIOPTimeoutTestCase.java:175)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years