[JBoss JIRA] (WFLY-6936) RebindTestCase fails with security manager
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFLY-6936?page=com.atlassian.jira.plugin.... ]
Ken Wills commented on WFLY-6936:
---------------------------------
FYI Ingo, the security manager change was merged into wildfly-core yesterday.
> RebindTestCase fails with security manager
> ------------------------------------------
>
> Key: WFLY-6936
> URL: https://issues.jboss.org/browse/WFLY-6936
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Jan Tymel
> Assignee: Ingo Weiss
> Fix For: 11.0.0.Alpha1
>
>
> *org.jboss.as.test.integration.naming.RebindTestCase#testRebinding*
> *org.jboss.as.test.integration.naming.RebindTestCase#testRebindingLookup*
> *org.jboss.as.test.integration.naming.RebindTestCase#testRebindingObjectFactory*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.naming.RebindTestCase#testRebinding -Dsecurity.manager}}
> Fails with:
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/RebindTestCase.jar <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:85)
> at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:120)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:64)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:139)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:114)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> ... 145 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (JGRP-2090) JGRP000027: failed passing message up
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2090?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2090:
--------------------------------
Right, this is what I usually recommend. Another option is to reduce the ip_ttl such that packets netween networks are dropped, or use VLANs altogether.
> JGRP000027: failed passing message up
> -------------------------------------
>
> Key: JGRP-2090
> URL: https://issues.jboss.org/browse/JGRP-2090
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Will Wright
> Assignee: Bela Ban
> Fix For: 3.6.11
>
>
> The JGroups library is generating NullPointerExceptions when attempting to process incoming messages. From what I can tell this is due to it looking for an incorrect message header.
> The TP object has a protocol id of 75 despite being a TUNNEL which ought to have an id of 24. The id is being correctly assigned to 24 at the Protocol.id member variable declaration, but is then subsequently changed to 75 by the TP.init method. This seems to have been caused by commit [6bc167f7e0181af32e1930935d8cf0efdc1e82f0|https://github.com/belaban/JGrou...] which has the message "Added TP to jg-protocols.xml". If I backout this change to the TP.init method so as to not update the id then my application receives the incoming messages fine.
> java.lang.NullPointerException: null
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1872)
> 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)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (JGRP-2090) JGRP000027: failed passing message up
by Paul Illingworth (JIRA)
[ https://issues.jboss.org/browse/JGRP-2090?page=com.atlassian.jira.plugin.... ]
Paul Illingworth commented on JGRP-2090:
----------------------------------------
I am seeing the same issue. For me the problem is that I am on a development network where there are several JGroups domains/clusters active all using the same UDP muticast addresses and ports but are differentiated by domain/cluster name. The other domains on the network are using JGroups 3.6.3 whilst I am using 3.6.11 - this means I get the NPE.
I can avoid the problem by changing my UDP multicast address or port to "physically" separate the domains/cluster instead of just relying on the domain name.
> JGRP000027: failed passing message up
> -------------------------------------
>
> Key: JGRP-2090
> URL: https://issues.jboss.org/browse/JGRP-2090
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Will Wright
> Assignee: Bela Ban
> Fix For: 3.6.11
>
>
> The JGroups library is generating NullPointerExceptions when attempting to process incoming messages. From what I can tell this is due to it looking for an incorrect message header.
> The TP object has a protocol id of 75 despite being a TUNNEL which ought to have an id of 24. The id is being correctly assigned to 24 at the Protocol.id member variable declaration, but is then subsequently changed to 75 by the TP.init method. This seems to have been caused by commit [6bc167f7e0181af32e1930935d8cf0efdc1e82f0|https://github.com/belaban/JGrou...] which has the message "Added TP to jg-protocols.xml". If I backout this change to the TP.init method so as to not update the id then my application receives the incoming messages fine.
> java.lang.NullPointerException: null
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1872)
> 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)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFLY-7721) Support module slots for foreign JMS bridges
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7721?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-7721:
----------------------------------------
There was a fairly general effort recently to make name:slot work for all such attributes.
It's even possible this is already done in master.
> Support module slots for foreign JMS bridges
> --------------------------------------------
>
> Key: WFLY-7721
> URL: https://issues.jboss.org/browse/WFLY-7721
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Robert Lee
> Assignee: Jeff Mesnil
> Labels: artemis, bridge, jmsbridge, modules, slot
>
> It would be nice to specify the slot, along with the module, for a JMS bridge.
> *Use case*:
> When setting up a JMS bridge with a foreign JMS system, the "module" option can be used (as a CLI parameter or an XML attribute) to specify the library code for the foreign JMS system, as a JBoss Module.
> We have a number of different versions of a legacy messaging API. We have previously set up modules for direct use within our deployed application code, using different slots for different versions of the foreign JMS system.
> We are now trying to migrate away from our different messaging systems towards Wildfly/Artemis, and have tried to set up JMS bridges to connect with the different systems.
> Unfortunately, it is not possible to use any module slot other than "main" with a JMS bridge. There is no "slot" attribute in the XML, and if we try to use "modulename:slot" notation, then we get an error saying that the module could not be loaded. Turning up debugging shows it is looking for "modulename\:slot:main".
> This seems like an omission, and is causing us to have to rework code to avoid the use of slots for different versions of the same library, which seems like a step backwards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFCORE-2035) Authorization Failures Starting After Enabling RBAC
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2035?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-2035:
-------------------------------------
Fix Version/s: 3.0.0.Alpha15
> Authorization Failures Starting After Enabling RBAC
> ---------------------------------------------------
>
> Key: WFCORE-2035
> URL: https://issues.jboss.org/browse/WFCORE-2035
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Security
> Reporter: Ingo Weiss
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Alpha15
>
>
> Enabling RBAC on WildFly is causing authorization failures on reload and it remains in unusable state afterwards. It is not possible to use neither CLI or Web Console thus it is not possible to configure or control server in any way.
> {noformat}
> 2016-11-22 14:43:27,256 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaTransactionManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaTransactionManager: WFLYTX0006: Failed to configure object store browser bean
> at org.jboss.as.txn.service.ArjunaTransactionManagerService.start(ArjunaTransactionManagerService.java:150)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 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)
> Caused by: javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1211)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1197)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:877)
> at com.arjuna.ats.arjuna.tools.osb.util.JMXServer.registerMBean(JMXServer.java:120)
> at com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser.start(ObjStoreBrowser.java:154)
> at org.jboss.as.txn.service.ArjunaTransactionManagerService.start(ArjunaTransactionManagerService.java:148)
> ... 5 more
> {noformat}
> {noformat}
> 2016-11-22 14:43:27,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.ws.config: org.jboss.msc.service.StartException in service jboss.ws.config: javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
> at org.jboss.as.webservices.service.ServerConfigService.start(ServerConfigService.java:73)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 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)
> Caused by: javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1211)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1197)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:877)
> at org.jboss.ws.common.management.AbstractServerConfig.create(AbstractServerConfig.java:343)
> at org.jboss.as.webservices.config.ServerConfigImpl.create(ServerConfigImpl.java:70)
> at org.jboss.as.webservices.service.ServerConfigService.start(ServerConfigService.java:70)
> ... 5 more
> {noformat}
> {noformat}
> 2016-11-22 14:43:30,434 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.clustering.infinispan.cache-container.web: org.jboss.msc.service.StartException in service org.wildfly.clustering.infinispan.cache-container.web: org.infinispan.commons.CacheException: Failure while registering mbeans
> at org.wildfly.clustering.service.FunctionalValueService.start(FunctionalValueService.java:69)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 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)
> Caused by: org.infinispan.commons.CacheException: Failure while registering mbeans
> at org.infinispan.jmx.ComponentsJmxRegistration.registerMBeans(ComponentsJmxRegistration.java:67)
> at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:38)
> at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:41)
> at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:657)
> at org.jboss.as.clustering.infinispan.subsystem.CacheContainerBuilder.lambda$build$3(CacheContainerBuilder.java:106)
> at org.wildfly.clustering.service.SuppliedValueService.lambda$new$0(SuppliedValueService.java:42)
> at org.wildfly.clustering.service.FunctionalValueService.start(FunctionalValueService.java:67)
> ... 5 more
> Caused by: javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1211)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1197)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.isRegistered(PluggableMBeanServerImpl.java:784)
> at org.infinispan.jmx.JmxUtil.registerMBean(JmxUtil.java:66)
> at org.infinispan.jmx.ComponentsJmxRegistration.registerMBeans(ComponentsJmxRegistration.java:64)
> ... 11 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFLY-4539) logging statement to trace remoting heartbeat
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4539?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-4539:
-----------------------------------
Issue Type: Enhancement (was: Feature Request)
> logging statement to trace remoting heartbeat
> ---------------------------------------------
>
> Key: WFLY-4539
> URL: https://issues.jboss.org/browse/WFLY-4539
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: Carsten Lichy-Bittendorf
> Assignee: Peter Palaga
> Priority: Minor
>
> you can set the heartbeat on a remoting connection by setting:
> remote.connection.default.connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL
> What is missing is the option to log on the client when the heartbeat message is fired.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFLY-4539) logging statement to trace remoting heartbeat
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/WFLY-4539?page=com.atlassian.jira.plugin.... ]
Peter Palaga commented on WFLY-4539:
------------------------------------
Assigned to me as agreed with [~tomekadamski]
> logging statement to trace remoting heartbeat
> ---------------------------------------------
>
> Key: WFLY-4539
> URL: https://issues.jboss.org/browse/WFLY-4539
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: Carsten Lichy-Bittendorf
> Assignee: Peter Palaga
> Priority: Minor
>
> you can set the heartbeat on a remoting connection by setting:
> remote.connection.default.connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL
> What is missing is the option to log on the client when the heartbeat message is fired.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFLY-4539) logging statement to trace remoting heartbeat
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/WFLY-4539?page=com.atlassian.jira.plugin.... ]
Peter Palaga reassigned WFLY-4539:
----------------------------------
Assignee: Peter Palaga (was: Tomasz Adamski)
> logging statement to trace remoting heartbeat
> ---------------------------------------------
>
> Key: WFLY-4539
> URL: https://issues.jboss.org/browse/WFLY-4539
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: Carsten Lichy-Bittendorf
> Assignee: Peter Palaga
> Priority: Minor
>
> you can set the heartbeat on a remoting connection by setting:
> remote.connection.default.connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL
> What is missing is the option to log on the client when the heartbeat message is fired.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months