[JBoss JIRA] (WFLY-4855) Test case for CXF-6469 (schemaLocation in xsd import is not rewritten)
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4855?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-4855:
-----------------------------
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.
> Test case for CXF-6469 (schemaLocation in xsd import is not rewritten)
> ----------------------------------------------------------------------
>
> Key: WFLY-4855
> URL: https://issues.jboss.org/browse/WFLY-4855
> Project: WildFly
> Issue Type: Enhancement
> Components: Test Suite
> Affects Versions: 10.0.0.Alpha4
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Fix For: 10.0.0.Final
>
>
> Adding a test case for CXF-6469 - verifying the schema imports are rewritten in various situations.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-5913) Add ability to specify external context on JNDI lookup binding
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5913?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-5913:
-----------------------------
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.
> Add ability to specify external context on JNDI lookup binding
> --------------------------------------------------------------
>
> Key: WFLY-5913
> URL: https://issues.jboss.org/browse/WFLY-5913
> Project: WildFly
> Issue Type: Feature Request
> Components: Naming
> Affects Versions: 10.0.0.CR5
> Reporter: Guillermo González de Agüero
> Fix For: 10.0.0.Final
>
>
> The Naming subsystem allows to create alias to JNDI lookups on the local context, and also allows to bind an external context to an entry. However, it isn't possible to bind a lookup to an external context.
> My personal use case is that I have an exported JMS Topic on a Remote WildFly. I'd like to be able to use it from my application like if it where local.
> For now, I've created an Object Factory that lookups the external context and then lookups the topic.
> An attribute indicating the context could be added. If none specified, local context should be used. Something like this:
> {code:xml}
> <bindings>
> <external-context name="java:/global/mqserver" module="org.jboss.as.naming" class="javax.naming.InitialContext" cache="true">
> <environment>
> <property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
> <property name="java.naming.provider.url" value="http-remoting://localhost:8290"/>
> <property name="java.naming.security.principal" value="remote"/>
> <property name="java.naming.security.credentials" value="remote"/>
> </environment>
> </external-context>
> <lookup name="java:/jms/topic/ImportedTopic" lookup="java:/jms/topic/MyTopic" externalContext="java:/global/mqserver"/>
> </bindings>
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[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, 5 months
[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, 5 months
[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, 5 months
[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, 5 months