[JBoss JIRA] (WFLY-9207) Typo in description of reverse-proxy host enable-http2 attribute
by Jan Stourac (JIRA)
[ https://issues.jboss.org/browse/WFLY-9207?page=com.atlassian.jira.plugin.... ]
Jan Stourac reassigned WFLY-9207:
---------------------------------
Assignee: Jan Stourac (was: Stuart Douglas)
> Typo in description of reverse-proxy host enable-http2 attribute
> ----------------------------------------------------------------
>
> Key: WFLY-9207
> URL: https://issues.jboss.org/browse/WFLY-9207
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Beta1
> Reporter: Jan Stourac
> Assignee: Jan Stourac
> Priority: Trivial
>
> There is a typo in description of the {{enable-http2}} attribute of the reverse-proxy host element:
> {code}
> /subsystem=undertow/configuration=handler/reverse-proxy=a/host=a:read-resource-description
> [...snip...]
> "description" => "If this is true then the proxy will attempt to use HTTP/2 to connect to the backend. If it is not supported it will fall back to HTTP/1.1/",
> [...snip...]
> {code}
> Forward slash at the end of the line should be removed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9207) Typo in description of reverse-proxy host enable-http2 attribute
by Jan Stourac (JIRA)
Jan Stourac created WFLY-9207:
---------------------------------
Summary: Typo in description of reverse-proxy host enable-http2 attribute
Key: WFLY-9207
URL: https://issues.jboss.org/browse/WFLY-9207
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 11.0.0.Beta1
Reporter: Jan Stourac
Assignee: Stuart Douglas
Priority: Trivial
There is a typo in description of the {{enable-http2}} attribute of the reverse-proxy host element:
{code}
/subsystem=undertow/configuration=handler/reverse-proxy=a/host=a:read-resource-description
[...snip...]
"description" => "If this is true then the proxy will attempt to use HTTP/2 to connect to the backend. If it is not supported it will fall back to HTTP/1.1/",
[...snip...]
{code}
Forward slash at the end of the line should be removed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9206) Restore support for security cache-container w/out a default-cache
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9206?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-12614 to WFLY-9206:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9206 (was: JBEAP-12614)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 11.0.0.Beta1
(was: 7.1.0.ER3)
> Restore support for security cache-container w/out a default-cache
> ------------------------------------------------------------------
>
> Key: WFLY-9206
> URL: https://issues.jboss.org/browse/WFLY-9206
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
>
> Commands from reproducer are succesful in 7.0. (Actually, in 7.0.7 it fails. This compatibility break in micro version will be tracked by another JIRA)
> In 7.1 these commands fail
> {code}
> /subsystem=security/security-domain=test:add(cache-type=infinispan)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0369: Required capabilities are not available:
> org.wildfly.clustering.infinispan.default-cache-configuration.security; There are no known registration points which can provide this capability.",
> "rolled-back" => true
> }
> {code}
> Also fails when copying standalone.xml from 7.0 to 7.1
> {code}
> 09:20:13,820 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=security/security-domain=test' are not available:
> org.wildfly.clustering.infinispan.default-cache-configuration.security; Possible registration points for this capability:
> /subsystem=infinispan/cache-container=*
> 09:20:13,823 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> This JIRA is created based on discussion from [1]
> Setting to blocker as from my Pov it could breaks RFE EAP7-482. Thus need proper triage.
> [1] http://post-office.corp.redhat.com/archives/jboss-support-eap6/2017-July/...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9205) The 'supports' of a HttpScope should not take into account the existence
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-9205:
--------------------------------------
Summary: The 'supports' of a HttpScope should not take into account the existence
Key: WFLY-9205
URL: https://issues.jboss.org/browse/WFLY-9205
Project: WildFly
Issue Type: Bug
Components: Security, Web (Undertow)
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 11.0.0.CR1
Callers to the API can call supports* and exists, the return value of supports* should not be dependent on the return value of exists as the caller may be checking if it is worth calling create.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JBJCA-1354) Potential for deadlock on pool's flush
by Flavia Rainone (JIRA)
Flavia Rainone created JBJCA-1354:
-------------------------------------
Summary: Potential for deadlock on pool's flush
Key: JBJCA-1354
URL: https://issues.jboss.org/browse/JBJCA-1354
Project: IronJacamar
Issue Type: Bug
Reporter: Flavia Rainone
Assignee: Flavia Rainone
There is a potential for deadlock on all flushes in pools. The problem is that flush is synchronized and inside the flush the code can be delegated to listeners, that are external to IronJacamar.
If those listeners use their own synchronization system , they could require synchronization locking in themselves. If there is another thread locking the listener and at some point invoking an operation that results in a pool flush, the system could enter a deadlock state.
An example of stack trace:
{noformat}
Found one Java-level deadlock:
=============================
"JMSCCThreadPoolWorker-18":
waiting to lock monitor 0x00007f1d2409ff48 (object 0x00000007853ad060, a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool),
which is held by "JMSCCThreadPoolWorker-16"
"JMSCCThreadPoolWorker-16":
waiting to lock monitor 0x00007f1d1c15d138 (object 0x0000000785998598, a com.ibm.mq.connector.outbound.ConnectionEventHandler),
which is held by "JMSCCThreadPoolWorker-17"
"JMSCCThreadPoolWorker-17":
waiting to lock monitor 0x00007f1d2409ff48 (object 0x00000007853ad060, a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool),
which is held by "JMSCCThreadPoolWorker-16"
Java stack information for the threads listed above:
===================================================
"JMSCCThreadPoolWorker-18":
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.flush(AbstractPool.java:322)
- waiting to lock <0x00000007853ad060> (a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool)
at org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:368)
at com.ibm.mq.connector.outbound.ConnectionEventHandler.fireEvent(ConnectionEventHandler.java:141)
- locked <0x0000000788fe1fa0> (a com.ibm.mq.connector.outbound.ConnectionEventHandler)
at com.ibm.mq.connector.outbound.ManagedConnectionImpl.onException(ManagedConnectionImpl.java:848)
at com.ibm.msg.client.jms.internal.JmsProviderExceptionListener.run(JmsProviderExceptionListener.java:427)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:214)
at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:105)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:229)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:303)
at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1241)
"JMSCCThreadPoolWorker-16":
at com.ibm.mq.connector.outbound.ConnectionEventHandler.removeListener(ConnectionEventHandler.java:93)
- waiting to lock <0x0000000785998598> (a com.ibm.mq.connector.outbound.ConnectionEventHandler)
at com.ibm.mq.connector.outbound.ManagedConnectionImpl.removeConnectionEventListener(ManagedConnectionImpl.java:434)
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.doDestroy(SemaphoreArrayListManagedConnectionPool.java:891)
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.flush(SemaphoreArrayListManagedConnectionPool.java:621)
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.flush(AbstractPool.java:330)
- locked <0x00000007853ad060> (a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool)
at org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:368)
at com.ibm.mq.connector.outbound.ConnectionEventHandler.fireEvent(ConnectionEventHandler.java:141)
- locked <0x0000000788fe20b0> (a com.ibm.mq.connector.outbound.ConnectionEventHandler)
at com.ibm.mq.connector.outbound.ManagedConnectionImpl.onException(ManagedConnectionImpl.java:848)
at com.ibm.msg.client.jms.internal.JmsProviderExceptionListener.run(JmsProviderExceptionListener.java:427)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:214)
at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:105)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:229)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:303)
at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1241)
"JMSCCThreadPoolWorker-17":
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.flush(AbstractPool.java:322)
- waiting to lock <0x00000007853ad060> (a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool)
at org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:368)
at com.ibm.mq.connector.outbound.ConnectionEventHandler.fireEvent(ConnectionEventHandler.java:141)
- locked <0x0000000785998598> (a com.ibm.mq.connector.outbound.ConnectionEventHandler)
at com.ibm.mq.connector.outbound.ManagedConnectionImpl.onException(ManagedConnectionImpl.java:848)
at com.ibm.msg.client.jms.internal.JmsProviderExceptionListener.run(JmsProviderExceptionListener.java:427)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:214)
at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:105)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:229)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:303)
at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1241)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8548) Annotations on overloaded methods are sometimes mixed up
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8548?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-8548:
--------------------------------------
Assignee: Olaf Fricke
> Annotations on overloaded methods are sometimes mixed up
> --------------------------------------------------------
>
> Key: WFLY-8548
> URL: https://issues.jboss.org/browse/WFLY-8548
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final, 11.0.0.Beta1
> Reporter: Olaf Fricke
> Assignee: Olaf Fricke
> Priority: Critical
> Attachments: ApplicableMethodInformationTest.java
>
>
> If a stateless session bean contains overloaded methods the annotations on these methods are sometimes mixed up. This happens for example, if two methods with the same name, the same return type and the same number of arguments exists. If both methods have different annotations or annotation values the values of the 'first' method are used.
> To make things more complicated, the 'first' method depends on the JVM in use.
> The bug lives in the class org.jboss.as.ejb3.deployment.ApplicableMethodInformation. I have already create a pull request to fix the issue: https://github.com/wildfly/wildfly/pull/9922
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JBJCA-1352) IBM MQ deadlock on shutdown
by Flavia Rainone (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1352?page=com.atlassian.jira.plugin... ]
Flavia Rainone resolved JBJCA-1352.
-----------------------------------
Resolution: Done
> IBM MQ deadlock on shutdown
> ---------------------------
>
> Key: JBJCA-1352
> URL: https://issues.jboss.org/browse/JBJCA-1352
> Project: IronJacamar
> Issue Type: Bug
> Components: AS
> Affects Versions: WildFly/IronJacamar 1.4.2.Final
> Environment: JBoss EAP 7.0.4
> Reporter: Doug Grove
> Assignee: Flavia Rainone
>
> Sporadically, on shut down, IBM MQ and JBoss will deadlock. This does not occur on EAP 6.
> The Deadlocking threads are
> [1]
> ~~~
> ServerService Thread Pool -- 63" #183 prio=5 os_prio=0 tid=0x00000000021ef800 nid=0x50e2 waiting for monitor entry [0x00007fef8451a000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at com.ibm.mq.connector.outbound.ConnectionEventHandler.removeListener(ConnectionEventHandler.java:93)
> - waiting to lock <0x000000009be01318> (a com.ibm.mq.connector.outbound.ConnectionEventHandler)
> at com.ibm.mq.connector.outbound.ManagedConnectionImpl.removeConnectionEventListener(ManagedConnectionImpl.java:434)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.doDestroy(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1376)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.flush(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:882)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.shutdown(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1065)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.shutdown(AbstractPool.java:930)
> - locked < 0x000000008d09b340> (a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.shutdown(AbstractConnectionManager.java:285)
> - locked < 0x000000008d09b2e0> (a org.jboss.jca.core.connectionmanager.notx.NoTxConnectionManagerImpl)
> at org.jboss.as.connector.services.resourceadapters.deployment.AbstractResourceAdapterDeploymentService.unregisterAll(AbstractResourceAdapterDeploymentService.java:192)
> at org.jboss.as.connector.services.resourceadapters.deployment.AbstractResourceAdapterDeploymentService$3.run(AbstractResourceAdapterDeploymentService.java:346)
> 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)
> ~~~
> [2]
> ~~~
> "DefaultMessageListenerContainer-2" #162 prio=5 os_prio=0 tid=0x0000000001d7a800 nid=0x46bf waiting for monitor entry [0x00007fef70a7d000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.shutdown(AbstractConnectionManager.java:281)
> - waiting to lock <0x000000008d09b2e0> (a org.jboss.jca.core.connectionmanager.notx.NoTxConnectionManagerImpl)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.returnManagedConnection(AbstractConnectionManager.java:724)
> at org.jboss.jca.core.connectionmanager.listener.NoTxConnectionListener.connectionClosed(NoTxConnectionListener.java:93)
> at com.ibm.mq.connector.outbound.ConnectionEventHandler.fireEvent(ConnectionEventHandler.java:135)
> - locked < 0x000000009be01318> (a com.ibm.mq.connector.outbound.ConnectionEventHandler)
> at com.ibm.mq.connector.outbound.ManagedConnectionImpl.fireConnectionClosed(ManagedConnectionImpl.java:784)
> at com.ibm.mq.connector.outbound.ConnectionWrapper.close(ConnectionWrapper.java:337)
> at org.springframework.jms.connection.ConnectionFactoryUtils.releaseConnection(ConnectionFactoryUtils.java:80)
> at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:358)
> at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:255)
> at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1166)
> at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1158)
> at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1055)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9204) Annotations on overloaded methods are sometimes mixed up
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-9204:
--------------------------------------
Summary: Annotations on overloaded methods are sometimes mixed up
Key: WFLY-9204
URL: https://issues.jboss.org/browse/WFLY-9204
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.1.0.Final, 11.0.0.Beta1
Reporter: Olaf Fricke
Priority: Critical
Attachments: ApplicableMethodInformationTest.java
If a stateless session bean contains overloaded methods the annotations on these methods are sometimes mixed up. This happens for example, if two methods with the same name, the same return type and the same number of arguments exists. If both methods have different annotations or annotation values the values of the 'first' method are used.
To make things more complicated, the 'first' method depends on the JVM in use.
The bug lives in the class org.jboss.as.ejb3.deployment.ApplicableMethodInformation. I have already create a pull request to fix the issue: https://github.com/wildfly/wildfly/pull/9922
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1694) Inherited kbases, across multiple modules, fails to build via the kie-maven-plugin
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1694?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1694:
-------------------------------------
[~swiderski.maciej] I quickly discussed this issue with [~mdessi] and reassigned to him. We decided to give a look at this together when we will meet next week (even if formally on vacation). Is this urgent? Should we give this higher priority?
> Inherited kbases, across multiple modules, fails to build via the kie-maven-plugin
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-1694
> URL: https://issues.jboss.org/browse/DROOLS-1694
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 6.3.0.Final
> Reporter: Alistair Black
> Assignee: Massimiliano Dessi
>
> I am working on a multi-module BRMS project, with each module encapsulating a set of rules forming a single knowledge base. There is a "packaging" module which inherits each of these modules in order to generate a KJAR for deployment purposes. The application then utilises this KJAR via the KieScanner/ReleaseId approach to facilitate dynamic rule loading at runtime and decoupling of application/rules.
> Having taken the above approach I have encountered an issue where the master build fails when building the "packaging" module as part of the main project build. If the module is built on it's own, then it completes without error.
> The error reported is:
> {{[ERROR] Failed to execute goal org.kie:kie-maven-plugin:6.3.0.Final:build (default-build) on project rules: Execution default-build of goal org.kie:kie-maven-plugin:6.3.0.Final:build failed: Illegal class for global. Expected [org.drools.template.parser.DefaultGenerator], found [org.drools.template.parser.DefaultGenerator]. -> [Help 1]}}
> Having liased with Maciej Swiderski he has asked me to report it as a bug.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months