[JBoss JIRA] (WFLY-3566) JMXSubsystemRemove is unsafe
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3566?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3566:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1087711|https://bugzilla.redhat.com/show_bug.cgi?id=1087711] from ASSIGNED to MODIFIED
> JMXSubsystemRemove is unsafe
> ----------------------------
>
> Key: WFLY-3566
> URL: https://issues.jboss.org/browse/WFLY-3566
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, JMX
> Affects Versions: 8.1.0.Final
> Reporter: Brian Stansberry
> Assignee: Kabir Khan
> Fix For: 9.0.0.Beta1
>
>
> The service installed by JMXSubsytemAdd is used by quite a few other subsystems (arquillian, infinispan, jgroups, jsr77, sar, perhaps something in webservices) but JMXSubsytemRemove just removes it.
> 1) Given the number of dependencies, the removal should require the allow-resource-service-restart header.
> 2) The rollbackRuntime method needs to be implemented.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3697) Custom http handlers support
by Nicky Mølholm (JIRA)
[ https://issues.jboss.org/browse/WFLY-3697?page=com.atlassian.jira.plugin.... ]
Nicky Mølholm commented on WFLY-3697:
-------------------------------------
[~ctomc] I am taking a shot at building this support. Hope it is okay? Currently asking for some practical advice on the IRC wildfly-dev channel
(Restricted to jira-users group)
> Custom http handlers support
> ----------------------------
>
> Key: WFLY-3697
> URL: https://issues.jboss.org/browse/WFLY-3697
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Fix For: 9.0.0.Beta1
>
>
> We need support for custom handlers & filters
> something along the lines
> {code:xml}
> <handlers>
> <handler name="myhandler" class="full.class.name" module"full.module.name" />
> <handlers>
> <filters>
> <filter name="myfilter" class="full.class.name" module"full.module.name" />
> <filters>
> {code}
> There should also be a way to pass in arbitrary config options
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3554) ejb-jar.xml interceptor-binding does not accept "*"
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3554?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski commented on WFLY-3554:
------------------------------------------
I did not test this, but this seems to be affecting only default interceptors. Also, if there is need to double def interceptors, this makes little sense.
> ejb-jar.xml interceptor-binding does not accept "*"
> ---------------------------------------------------
>
> Key: WFLY-3554
> URL: https://issues.jboss.org/browse/WFLY-3554
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.1.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: Bartosz Baranowski
> Fix For: 8.2.0.CR1, 9.0.0.Beta1
>
>
> From the ejb3.1 specification (JSR 318) chapter 12.7 Specification of Interceptors in the Deployment Descriptor:
> ""
> In the interceptor-binding element, the target-name element must be the name of one of
> the enterprise beans contained in the ejb-jar or the wildcard value “*”.
> ""
> But the "*" as ejb-name is ignored, only a bean name will result in binding the interceptor during deployment
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3266) Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3266?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3266:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1088463, https://bugzilla.redhat.com/show_bug.cgi?id=1127593 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1088463)
> Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3266
> URL: https://issues.jboss.org/browse/WFLY-3266
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Priority: Critical
>
> In case of large parameter input for EJB invocations the ejb-client throw the Exception below.
> The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found.
> java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
> at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy6.uploadData(Unknown Source)
> at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3719) Missing <uri> in the tld files causes NullPointerException during deployment on WildFly
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3719?page=com.atlassian.jira.plugin.... ]
Jay Kumar SenSharma updated WFLY-3719:
--------------------------------------
Workaround Description: - Make sure that the TLDs contain <uri> tag in it. (was: - Make sure that the TLDs contain <URI> tag in it.)
> Missing <uri> in the tld files causes NullPointerException during deployment on WildFly
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3719
> URL: https://issues.jboss.org/browse/WFLY-3719
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 9.0.0.Beta1
> Reporter: Jay Kumar SenSharma
> Assignee: Stuart Douglas
> Attachments: TagClassDemo.war
>
>
> - If The TLD file has missing *<uri>* tag in it then rather than validating WildFly throws NullPointerException.
> *WEB-INF/custom.tld*
> {code}
> <taglib>
> <tlib-version>1.0</tlib-version>
> <jsp-version>2.0</jsp-version>
> <!--uri>test</uri-->
> <short-name>Example TLD with Body</short-name>
> <tag>
> <name>Hello</name>
> <tag-class>tags.HelloTag</tag-class>
> <body-content>scriptless</body-content>
> </tag>
> </taglib>
> {code}
> - During deployment of a war containing above TLD causes following NullPointerException on WildFly:
> {code}
> 13:15:25,857 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createTldsInfo(UndertowDeploymentInfoService.java:1028)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:552)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:252)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> ... 3 more
> 13:15:25,865 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService: Failed to start service
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3719) Missing <uri> in the tld files causes NullPointerException during deployment on WildFly
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3719?page=com.atlassian.jira.plugin.... ]
Jay Kumar SenSharma updated WFLY-3719:
--------------------------------------
Attachment: TagClassDemo.war
> Missing <uri> in the tld files causes NullPointerException during deployment on WildFly
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3719
> URL: https://issues.jboss.org/browse/WFLY-3719
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 9.0.0.Beta1
> Reporter: Jay Kumar SenSharma
> Assignee: Stuart Douglas
> Attachments: TagClassDemo.war
>
>
> - If The TLD file has missing *<uri>* tag in it then rather than validating WildFly throws NullPointerException.
> *WEB-INF/custom.tld*
> {code}
> <taglib>
> <tlib-version>1.0</tlib-version>
> <jsp-version>2.0</jsp-version>
> <!--uri>test</uri-->
> <short-name>Example TLD with Body</short-name>
> <tag>
> <name>Hello</name>
> <tag-class>tags.HelloTag</tag-class>
> <body-content>scriptless</body-content>
> </tag>
> </taglib>
> {code}
> - During deployment of a war containing above TLD causes following NullPointerException on WildFly:
> {code}
> 13:15:25,857 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createTldsInfo(UndertowDeploymentInfoService.java:1028)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:552)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:252)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> ... 3 more
> 13:15:25,865 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService: Failed to start service
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3719) Missing <uri> in the tld files causes NullPointerException during deployment on WildFly
by Jay Kumar SenSharma (JIRA)
Jay Kumar SenSharma created WFLY-3719:
-----------------------------------------
Summary: Missing <uri> in the tld files causes NullPointerException during deployment on WildFly
Key: WFLY-3719
URL: https://issues.jboss.org/browse/WFLY-3719
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 9.0.0.Beta1
Reporter: Jay Kumar SenSharma
Assignee: Stuart Douglas
- If The TLD file has missing *<uri>* tag in it then rather than validating WildFly throws NullPointerException.
*WEB-INF/custom.tld*
{code}
<taglib>
<tlib-version>1.0</tlib-version>
<jsp-version>2.0</jsp-version>
<!--uri>test</uri-->
<short-name>Example TLD with Body</short-name>
<tag>
<name>Hello</name>
<tag-class>tags.HelloTag</tag-class>
<body-content>scriptless</body-content>
</tag>
</taglib>
{code}
- During deployment of a war containing above TLD causes following NullPointerException on WildFly:
{code}
13:15:25,857 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: java.lang.NullPointerException
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createTldsInfo(UndertowDeploymentInfoService.java:1028)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:552)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:252)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
... 3 more
13:15:25,865 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService: Failed to start service
Caused by: java.lang.NullPointerException"}}
{code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3718) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
by Gabor Auth (JIRA)
[ https://issues.jboss.org/browse/WFLY-3718?page=com.atlassian.jira.plugin.... ]
Gabor Auth commented on WFLY-3718:
----------------------------------
I using TCP transport with tcpping stack (the nodes are in DigitalOcean cloud, they have not support UDP multicast).
The relevant part of my domain.xml:
<subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="tcpping">
<stack name="udp">
... original content ...
</stack>
<stack name="tcp">
... original content ...
</stack>
<stack name="tcpping">
<transport type="TCP" socket-binding="jgroups-tcp"/>
<protocol type="TCPPING">
<property name="port_range">
0
</property>
<property name="timeout">
3000
</property>
<property name="num_initial_members">
2
</property>
<property name="initial_hosts">
10.129.171.246[7750],10.129.211.128[7750],10.129.215.37[7750]
</property>
</protocol>
<protocol type="MERGE2"/>
<protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="BARRIER"/>
<protocol type="pbcast.NAKACK"/>
<protocol type="UNICAST2"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="UFC"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
<protocol type="RSVP"/>
</stack>
</subsystem>
> UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3718
> URL: https://issues.jboss.org/browse/WFLY-3718
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: WildFly 8.1.0.Final
> Reporter: Gabor Auth
> Assignee: Paul Ferraro
>
> 2014-07-30 02:12:30,088 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:62) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
> 2014-07-30 02:12:30,786 ERROR [io.undertow.request] (default task-15) Blocking request failed HttpServerExchange{ GET /frontend/images/favicon.ico}: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:711)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:137)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months