July 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1743) Update to web console 2.0.0.Final

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFLY-1743?page=com.atlassian.jira.plugin.... ] Heiko Braun updated WFLY-1743: ------------------------------ Component/s: Web Console > Update to web console 2.0.0.Final > --------------------------------- > > Key: WFLY-1743 > URL: https://issues.jboss.org/browse/WFLY-1743 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, Web Console > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 8.0.0.Final > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1742) WebConsole: AccessContol for action cells

by Heiko Braun (JIRA)

Heiko Braun created WFLY-1742: --------------------------------- Summary: WebConsole: AccessContol for action cells Key: WFLY-1742 URL: https://issues.jboss.org/browse/WFLY-1742 Project: WildFly Issue Type: Bug Components: Web Console Reporter: Heiko Braun Assignee: Heiko Braun in some cases we use inline celltable cell buttons. these need to be considered when access control comes into play. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (AS7-4932) CLONE - Using session passivation results in WeldListener: java.lang.NullPointerException on normal operation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-4932?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-4932: ---------------------------------------------- Radoslav Husar <rhusar(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] Just noting that the fix is not relevant upstream (different implementation). > CLONE - Using session passivation results in WeldListener: java.lang.NullPointerException on normal operation > ------------------------------------------------------------------------------------------------------------- > > Key: AS7-4932 > URL: https://issues.jboss.org/browse/AS7-4932 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Affects Versions: 7.1.2.Final (EAP) > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Priority: Blocker > Labels: as713tracking > Fix For: 7.1.3.Final (EAP) > > > NPE is thrown in roughly 0.36% of HTTP session request processing in the test. > This results in response code 503 returned to the client with the exception. > The test is using passivation-enabled WAR of clusterbench > https://github.com/rhusar/clusterbench > Here is a shorter soak test run that uncovered the issue > https://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Clustering-Soak/jo... > {noformat} > [JBossINF] 19:52:10,113 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (ajp-perf20/10.16.90.58:8009-2570) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.NullPointerException > [JBossINF] at org.jboss.as.web.session.ClusteredSession.update(ClusteredSession.java:972) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1377) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:673) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > [JBossINF] at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.16.Final-redhat-1.jar:] > [JBossINF] at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.16.Final-redhat-1.jar:] > [JBossINF] at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.16.Final-redhat-1.jar:] > [JBossINF] at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1] > [JBossINF] at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1] > [JBossINF] at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1] > [JBossINF] at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1] > [JBossINF] at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1] > [JBossINF] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.16.Final-redhat-1.jar:] > [JBossINF] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final-redhat-1.jar:] > [JBossINF] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final-redhat-1.jar:] > [JBossINF] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final-redhat-1.jar:] > [JBossINF] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.16.Final-redhat-1.jar:] > [JBossINF] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:452) [jbossweb-7.0.16.Final-redhat-1.jar:] > [JBossINF] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final-redhat-1.jar:] > [JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30] > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-157) drools-compiler depends on antlr 2.7.7 and 3.3. Upgrade to antlr 3.4 to avoid having to depend on 2.x and 3.x at the same time

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-157?page=com.atlassian.jira.plugin... ] Geoffrey De Smet reassigned DROOLS-157: --------------------------------------- Assignee: Edson Tirelli (was: Geoffrey De Smet) Edson, many users complained about this on the mailing list in the past. 2 years ago they hadn't released fixes yet, so it wasn't fixable. Now it should be relatively easy. > drools-compiler depends on antlr 2.7.7 and 3.3. Upgrade to antlr 3.4 to avoid having to depend on 2.x and 3.x at the same time > ------------------------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-157 > URL: https://issues.jboss.org/browse/DROOLS-157 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Marcel May > Assignee: Edson Tirelli > Priority: Critical > Labels: maven > > drools-compiler uses antlr 3.3 but has an additional dependency on old antlr:antlr 2.7.7 version. > The v2 dependency is obsolete since antlr 3.1 (see http://www.antlr.org/jira/browse/ANTLR-180). > Please remove the antlr:antlr dependency, for the next 5.2.x / 5.3.x release - thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1664) UNICAST3: ack on reception versus ack on delivery

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1664?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1664: --------------------------- Fix Version/s: 3.3.4 > UNICAST3: ack on reception versus ack on delivery > ------------------------------------------------- > > Key: JGRP-1664 > URL: https://issues.jboss.org/browse/JGRP-1664 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3.4, 3.4 > > > In UNICAST3, if ack_batches_immediately is true, a message batch is acked *before* delivering it. So this is basically acking on *reception* rather than *delivery*. > However, this is not done for single messages. I could change the ack_batches_immediately to ack_on_reception, and - if true - ack single messages also before they're delivered. > Thus we'd have a single property which governs whether single messages or message batches are acked on reception or delivery. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1664) UNICAST3: ack on reception versus ack on delivery

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1664?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1664. ---------------------------- Resolution: Done > UNICAST3: ack on reception versus ack on delivery > ------------------------------------------------- > > Key: JGRP-1664 > URL: https://issues.jboss.org/browse/JGRP-1664 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3.4, 3.4 > > > In UNICAST3, if ack_batches_immediately is true, a message batch is acked *before* delivering it. So this is basically acking on *reception* rather than *delivery*. > However, this is not done for single messages. I could change the ack_batches_immediately to ack_on_reception, and - if true - ack single messages also before they're delivered. > Thus we'd have a single property which governs whether single messages or message batches are acked on reception or delivery. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1741) RBAC: Response headers don't match payload structure

by Heiko Braun (JIRA)

Heiko Braun created WFLY-1741: --------------------------------- Summary: RBAC: Response headers don't match payload structure Key: WFLY-1741 URL: https://issues.jboss.org/browse/WFLY-1741 Project: WildFly Issue Type: Feature Request Components: Domain Management Reporter: Heiko Braun Assignee: Brian Stansberry the "relative-address" header doesn't match the response structure: {noformat} [standalone@localhost:9990 /] /subsystem=datasources:read-children-resources(child-type=data-source){roles=monitor} { "outcome" => "success", "result" => { "ExampleDS" => { "allocation-retry" => undefined, "allocation-retry-wait-millis" => undefined, [...] } }, "response-headers" => {"access-control" => [ { "absolute-address" => [ ("subsystem" => "datasources"), ("data-source" => "ExampleDS") ], "relative-address" => [("data-source" => "ExampleDS")], "filtered-attributes" => [ "user-name", "security-domain", "password" ] } ]} } {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1741) RBAC: Response headers don't match payload structure

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFLY-1741?page=com.atlassian.jira.plugin.... ] Heiko Braun updated WFLY-1741: ------------------------------ Issue Type: Bug (was: Feature Request) > RBAC: Response headers don't match payload structure > ---------------------------------------------------- > > Key: WFLY-1741 > URL: https://issues.jboss.org/browse/WFLY-1741 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Heiko Braun > Assignee: Brian Stansberry > > the "relative-address" header doesn't match the response structure: > {noformat} > [standalone@localhost:9990 /] /subsystem=datasources:read-children-resources(child-type=data-source){roles=monitor} > { > "outcome" => "success", > "result" => { > "ExampleDS" => { > "allocation-retry" => undefined, > "allocation-retry-wait-millis" => undefined, > [...] } > }, > "response-headers" => {"access-control" => [ { > "absolute-address" => [ > ("subsystem" => "datasources"), > ("data-source" => "ExampleDS") > ], > "relative-address" => [("data-source" => "ExampleDS")], > "filtered-attributes" => [ > "user-name", > "security-domain", > "password" > ] > } > ]} > } > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1741) RBAC: Response headers don't match payload structure

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFLY-1741?page=com.atlassian.jira.plugin.... ] Heiko Braun updated WFLY-1741: ------------------------------ Description: the 'relative-address' header doesn't match the response structure: (hint: the 'data-source' element is missing) {noformat} [standalone@localhost:9990 /] /subsystem=datasources:read-children-resources(child-type=data-source){roles=monitor} { "outcome" => "success", "result" => { "ExampleDS" => { "allocation-retry" => undefined, "allocation-retry-wait-millis" => undefined, [...] } }, "response-headers" => {"access-control" => [ { "absolute-address" => [ ("subsystem" => "datasources"), ("data-source" => "ExampleDS") ], "relative-address" => [("data-source" => "ExampleDS")], "filtered-attributes" => [ "user-name", "security-domain", "password" ] } ]} } {noformat} was: the "relative-address" header doesn't match the response structure: {noformat} [standalone@localhost:9990 /] /subsystem=datasources:read-children-resources(child-type=data-source){roles=monitor} { "outcome" => "success", "result" => { "ExampleDS" => { "allocation-retry" => undefined, "allocation-retry-wait-millis" => undefined, [...] } }, "response-headers" => {"access-control" => [ { "absolute-address" => [ ("subsystem" => "datasources"), ("data-source" => "ExampleDS") ], "relative-address" => [("data-source" => "ExampleDS")], "filtered-attributes" => [ "user-name", "security-domain", "password" ] } ]} } {noformat} > RBAC: Response headers don't match payload structure > ---------------------------------------------------- > > Key: WFLY-1741 > URL: https://issues.jboss.org/browse/WFLY-1741 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Heiko Braun > Assignee: Brian Stansberry > > the 'relative-address' header doesn't match the response structure: > (hint: the 'data-source' element is missing) > {noformat} > [standalone@localhost:9990 /] /subsystem=datasources:read-children-resources(child-type=data-source){roles=monitor} > { > "outcome" => "success", > "result" => { > "ExampleDS" => { > "allocation-retry" => undefined, > "allocation-retry-wait-millis" => undefined, > [...] } > }, > "response-headers" => {"access-control" => [ { > "absolute-address" => [ > ("subsystem" => "datasources"), > ("data-source" => "ExampleDS") > ], > "relative-address" => [("data-source" => "ExampleDS")], > "filtered-attributes" => [ > "user-name", > "security-domain", > "password" > ] > } > ]} > } > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1664) UNICAST3: ack on reception versus ack on delivery

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1664?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1664: -------------------------------- We now send acks after the *reception* and not the *delivery* of a message. > UNICAST3: ack on reception versus ack on delivery > ------------------------------------------------- > > Key: JGRP-1664 > URL: https://issues.jboss.org/browse/JGRP-1664 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4 > > > In UNICAST3, if ack_batches_immediately is true, a message batch is acked *before* delivering it. So this is basically acking on *reception* rather than *delivery*. > However, this is not done for single messages. I could change the ack_batches_immediately to ack_on_reception, and - if true - ack single messages also before they're delivered. > Thus we'd have a single property which governs whether single messages or message batches are acked on reception or delivery. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2013