[JBoss JIRA] (WFLY-4661) Provide Support for Clustered Singleton MDBs
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4661?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-4661:
-----------------------------
Fix Version/s: 10.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Provide Support for Clustered Singleton MDBs
> --------------------------------------------
>
> Key: WFLY-4661
> URL: https://issues.jboss.org/browse/WFLY-4661
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, JMS
> Affects Versions: 10.0.0.Alpha1
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Priority: Minor
> Fix For: 10.0.0.Final
>
>
> Provide Support for Clustered Singleton MDBs.
> Provide annotation and configuration support to mark such MDB deployments Clustered Singleton MDBs.
> When "Clustered Singleton MDBs" are deployed in a cluster; only one node (server) is active to consume messages serially. When the node fails; another the active node's "Clustered Singleton MDBs" starts consuming the messages.
> To mark an MDB as clustered singleton, one can either use the clustered-singleton xml element, like this:
> <jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
> xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:c="urn:clustering:1.1"
> xmlns:d="urn:delivery-active:1.1"
> xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
> version="3.1"
> impl-version="2.0">
> <c:clustering>
> <ejb-name>HelloWorldQueueMDB</ejb-name>
> <c:clustered-singleton>true</c:clustered-singleton>
> </c:clustering>
> </jboss:ejb-jar>
> Or one can use the @org.jboss.ejb3.annotation.ClusteredSingleton in your MDB class.
> This feature requires no extra configuration at the server, apart from running the service in a cluster.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-2490) Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-2490?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-2490:
-----------------------------
Fix Version/s: 10.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-2490
> URL: https://issues.jboss.org/browse/WFLY-2490
> Project: WildFly
> Issue Type: Sub-task
> Components: CLI, Remoting
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 10.0.0.Final
>
>
> HTTP Upgrade is not fully working when SSL is enabled, other tasks will address that but this issue is about the CLI connecting to a server where HTTP Upgrade is not possible - a thread within the CLI is left running at 100% even after connecting has timed out.
> {noformat}
> [disconnected /] connect https-remoting://localhost:9993
> The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> {noformat}
> Connecting to the HTTP port where HTTP Upgrade is not available also results in a time out connecting rather than an early failure but does not result in the thread spinning at 100%
> {noformat}
> [disconnected /] connect http-remoting://localhost:9990
> The controller is not available at localhost:9990: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-5142) JMS client which does not specify user/password during creating connection to server is not considered as "guest"
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5142?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-5142:
-----------------------------
Fix Version/s: 10.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> JMS client which does not specify user/password during creating connection to server is not considered as "guest"
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5142
> URL: https://issues.jboss.org/browse/WFLY-5142
> Project: WildFly
> Issue Type: Bug
> Components: Documentation, JMS
> Affects Versions: 10.0.0.Beta1
> Environment: Fedora 22
> openjdk 8
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Fix For: 10.0.0.Final
>
> Attachments: application-roles.properties, standalone-full-ha.xml
>
>
> Although remote calls requires to create an user and use explicit user credentials, in EAP 6 there is an workaround for that, see [JBPAPP6-1529|https://issues.jboss.org/browse/JBPAPP6-1529]. However, when I test the workaround in EAP 7, the JMS client is not considered as "guest" user.
> {noformat}
> javax.jms.JMSSecurityException: AMQ119031: Unable to validate user: null
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:410)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:335)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:262)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionChannel(ClientSessionFactoryImpl.java:1540)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:744)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:311)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnection.authorize(ActiveMQConnection.java:720)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:819)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:170)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:165)
> at org.jboss.qa.hornetq.test.security.SecurityClient.getConnection(SecurityClient.java:409)
> at org.jboss.qa.hornetq.test.security.SecurityClient.initializeClient(SecurityClient.java:114)
> at org.jboss.qa.hornetq.test.security.PermissionSecurityTestCase.testSecurityWithGuest(PermissionSecurityTestCase.java:123)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-5208) UT005023: Exception handling request: NullPointerException
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5208?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-5208:
-----------------------------
Fix Version/s: 10.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> UT005023: Exception handling request: NullPointerException
> ----------------------------------------------------------
>
> Key: WFLY-5208
> URL: https://issues.jboss.org/browse/WFLY-5208
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: Michal Vinkler
> Assignee: Stuart Douglas
> Fix For: 10.0.0.Final
>
>
> Setup: 4-node cluster, one node at time either shuts down or undeploys application (clusterbench-ee7.ear), and then recovers after period of time, while standalone clients keep calling the application.
> This error was seen during clustering failover testing in the following scenarios:
> ejb-ejbservlet-shutdown-repl-async (failover of HTTP traffic accessing a servlet that locally invokes a stateful clustered EJB, failover type: server shutdown, with asynchronously replicated cache)
> ejb-ejbservlet-shutdown-repl-sync (the same as above, with synchronously replicated cache)
> ejb-ejbservlet-undeploy-dist-sync (failover type: application undeploy, with distributed cache which is replicated synchronously)
> It occurs in these two situations (intermittently):
> 1. server startup after previous shutdown
> {code}
> [JBossINF] [0m[0m17:23:14,240 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0002: Started repl cache from web container
> [JBossINF] [0m[0m17:23:14,247 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 67) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-default.war cache from web container
> [JBossINF] [0m[0m17:23:14,374 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 66) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m17:23:14,375 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 66) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m17:23:15,708 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 65) Initializing Mojarra 2.2.12-jbossorg-2 20150729-1131 for context '/clusterbench'
> [JBossINF] [0m[0m17:23:15,708 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 71) Initializing Mojarra 2.2.12-jbossorg-2 20150729-1131 for context '/clusterbench-passivating'
> [JBossINF] [0m[0m17:23:16,784 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 71) WFLYUT0021: Registered web context: /clusterbench-passivating
> [JBossINF] [0m[0m17:23:17,198 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 65) WFLYUT0021: Registered web context: /clusterbench
> [JBossINF] [0m[31m17:23:18,931 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /clusterbench/ejbservlet: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.isRemoved(StatefulSessionObjectReferenceImpl.java:133)
> [JBossINF] at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:122)
> [JBossINF] at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> [JBossINF] at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> [JBossINF] at org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB$Proxy$_$$_Weld$EnterpriseProxy$.getSerialAndIncrement(Unknown Source)
> [JBossINF] at org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB$Proxy$_$$_WeldClientProxy.getSerialAndIncrement(Unknown Source)
> [JBossINF] at org.jboss.test.clusterbench.web.ejb.LocalEjbServlet.doGet(LocalEjbServlet.java:38)
> [JBossINF] at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> [JBossINF] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> [JBossINF] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> [JBossINF] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> [JBossINF] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> [JBossINF] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> [JBossINF] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> [JBossINF] at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> 2. Server shutdown/application undeploy
> {code}
> [JBossINF] [0m[0m18:04:35,977 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0211: Suspending server
> [JBossINF] [0m[0m18:04:35,981 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> 2015/08/18 18:04:36:037 EDT [DEBUG][RMI TCP Connection(14)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - [SHUTDOWN] JBossShutdown command executed successfully.
> 2015/08/18 18:04:36:037 EDT [DEBUG][RMI TCP Connection(14)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Waiting for server to shutdown.
> [JBossINF] [0m[0m18:04:36,048 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 77) WFLYUT0022: Unregistered web context: /clusterbench-passivating
> [JBossINF] [0m[0m18:04:36,063 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 81) WFLYUT0022: Unregistered web context: /clusterbench
> [JBossINF] [0m[0m18:04:36,072 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 82) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[31m18:04:36,106 ERROR [io.undertow.request] (default task-63) UT005023: Exception handling request to /clusterbench/ejbservlet: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.isRemoved(StatefulSessionObjectReferenceImpl.java:133)
> [JBossINF] at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:122)
> [JBossINF] at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> [JBossINF] at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> [JBossINF] at org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB$Proxy$_$$_Weld$EnterpriseProxy$.getSerialAndIncrement(Unknown Source)
> [JBossINF] at org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB$Proxy$_$$_WeldClientProxy.getSerialAndIncrement(Unknown Source)
> [JBossINF] at org.jboss.test.clusterbench.web.ejb.LocalEjbServlet.doGet(LocalEjbServlet.java:38)
> [JBossINF] at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> [JBossINF] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> [JBossINF] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> [JBossINF] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> [JBossINF] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> [JBossINF] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> [JBossINF] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> [JBossINF] at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> During server shutdown, it occurred also with different stacktrace:
> {code}
> [JBossINF] [0m[31m17:19:11,728 ERROR [io.undertow.request] (default task-128) UT005023: Exception handling request to /clusterbench/ejbservlet: java.lang.NullPointerException
> [JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:143)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:281)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF]
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-2318) Access control exceptions missing for scoped roles
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-2318?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-2318:
-----------------------------
Fix Version/s: 10.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Access control exceptions missing for scoped roles
> --------------------------------------------------
>
> Key: WFLY-2318
> URL: https://issues.jboss.org/browse/WFLY-2318
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Harald Pehl
> Fix For: 10.0.0.Final
>
>
> The following setup: user with two scoped roles assigned. maintainer for "main-servers", monitor for "other-servers". Requesting the access control meta data for the server group wildcard ]does not include "exceptions".
> Expected result: the access control meta data response contains an "exception" for each server group (main-server-group & other-server-group)
> {code}
> [domain@localhost:9999 /] ./server-group=*:read-resource-description(access-control=trim-descriptions, operations=true){roles=main-servers, other-servers}
> {
> "outcome" => "success",
> "result" => [{
> "address" => [("server-group" => "*")],
> "outcome" => "success",
> "result" => {
> "description" => undefined,
> "attributes" => undefined,
> "operations" => undefined,
> "children" => {
> "deployment" => {"model-description" => undefined},
> "system-property" => {"model-description" => undefined},
> "jvm" => {"model-description" => undefined},
> "deployment-overlay" => {"model-description" => undefined}
> },
> "access-control" => {
> "default" => {
> "read" => true,
> "write" => true,
> "attributes" => {
> "socket-binding-port-offset" => {
> "read" => true,
> "write" => true
> },
> "management-subsystem-endpoint" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-group" => {
> "read" => true,
> "write" => true
> },
> "profile" => {
> "read" => true,
> "write" => true
> }
> },
> "operations" => {
> "read-children-names" => {"execute" => true},
> "read-operation-description" => {"execute" => true},
> "remove" => {"execute" => true},
> "read-resource-description" => {"execute" => true},
> "stop-servers" => {"execute" => true},
> "read-resource" => {"execute" => true},
> "add" => {"execute" => true},
> "read-attribute" => {"execute" => true},
> "whoami" => {"execute" => true},
> "read-children-types" => {"execute" => true},
> "read-operation-names" => {"execute" => true},
> "undefine-attribute" => {"execute" => true},
> "start-servers" => {"execute" => true},
> "read-children-resources" => {"execute" => true},
> "restart-servers" => {"execute" => true},
> "replace-deployment" => {"execute" => true},
> "write-attribute" => {"execute" => true}
> }
> },
> "exceptions" => {}
> }
> }
> }]
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-4905) CacheRemoveHandler can't run in same op as remove of parent cache-container
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4905?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-4905:
-----------------------------
Fix Version/s: 10.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> CacheRemoveHandler can't run in same op as remove of parent cache-container
> ---------------------------------------------------------------------------
>
> Key: WFLY-4905
> URL: https://issues.jboss.org/browse/WFLY-4905
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Alpha4
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 10.0.0.Final
>
>
> CacheRemoveHandler tries to read its parent resource in Stage.RUNTIME, which means it can't run in the same op (say a composite) with a remove of the parent, as the parent resource will be gone by RUNTIME.
> This will also interfere with the WFCORE-808 improvement.
> Easy fix, as the read of the parent resource looks to be cruft; the data is never used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-1460) WildFly server fails to start with transactions configured to be run with JDBCObject store
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-1460?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-1460:
-----------------------------
Fix Version/s: 10.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> WildFly server fails to start with transactions configured to be run with JDBCObject store
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-1460
> URL: https://issues.jboss.org/browse/WFLY-1460
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 8.0.0.Alpha1
> Reporter: Ondra Chaloupka
> Assignee: Stefano Maestri
> Fix For: 10.0.0.Final
>
>
> In case that you configure transactions subsystem for running with JDBCObject store the app server fails to start because of (it seems so) a circular dependency.
> You can expect the exception like:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 52) JBAS014612: Operation ("add") failed - address: ([("subsystem" => "transactions")]): org.jboss.msc.service.CircularDependencyException: Container jboss-as has a circular dependency: [service jboss.txn.ArjunaObjectStoreEnvironment, service jboss.txn.ArjunaRecoveryManager, service jboss.connector.transactionintegration, service jboss.cached-connection-manager, service jboss.data-source.java:jboss/datasources/JDBCObjectDS]
> {code}
> My assumption came from the configuration similar to this:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/JDBCObjectDS" pool-name="JDBCObjectDS" enabled="true" use-ccm="false">
> <connection-url>jdbc:postgresql://postgresserver.com:5432/user1</connection-url>
> <driver-class>org.postgresql.Driver</driver-class>
> <driver>postgresql-9.2-1002.jdbc4.jar</driver>
> <security>
> <user-name>user1</user-name>
> <password>user1</password>
> </security>
> </datasource>
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/JDBCObjectDS" />
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-4441) web.xml parser process cannot handle exception for xml file which does not have the encoding attribute
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4441?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-4441:
-----------------------------
Fix Version/s: 9.0.0.Final
> web.xml parser process cannot handle exception for xml file which does not have the encoding attribute
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4441
> URL: https://issues.jboss.org/browse/WFLY-4441
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.0.Alpha1
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Fix For: 9.0.0.Final
>
>
> Description copied from https://bugzilla.redhat.com/show_bug.cgi?id=1184292
> Description of problem:
> When XMLStreamException occurs by web.xml parser process for xml file which does not have the encoding attribute, e.getLocation()[1] is null. We cannot find cause of exception by NullPointerException.
> [1]
> - org.jboss.as.web.deployment.WebParsingDeploymentProcessor.java
> #115 } catch (XMLStreamException e) {
> -> #116 throw new DeploymentUnitProcessingException(MESSAGES.failToParseXMLDescriptor(webXml, e.getLocation().getLineNumber(), e.getLocation().getColumnNumber()), e);
> #117 } catch (IOException e) {
> #118 throw new DeploymentUnitProcessingException(MESSAGES.failToParseXMLDescriptor(webXml), e);
> #119 }
> Version-Release number of selected component (if applicable):
> EAP 6.3.2
> How reproducible:
> Attached web.xml for reproducing.
> Steps to Reproduce:
> 1. Create war application using attached web.xml.
> 2. Deploy war to EAP.
> 3. Start EAP.
> Actual results:
> You can confirm NullPointerException.
> 15:56:23,190 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."test.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".PARSE: JBAS018733: Failed to process phase PARSE of deployment "test.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_71]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_71]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_71]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.web.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:116)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [jboss-as-server-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> ... 5 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month