April 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3169) Add JMX notifications for management resources

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-3169?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-3169: ------------------------------ Fix Version/s: 9.0.0.CR1 > Add JMX notifications for management resources > ---------------------------------------------- > > Key: WFLY-3169 > URL: https://issues.jboss.org/browse/WFLY-3169 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JMX > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.CR1 > > > Based on WFLY-266, the JMX subsystem could provide standard JMX notifications for resource registered/unregistered and changes of attributes values. -- 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

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-266) Add Notification support to the domain management API

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-266?page=com.atlassian.jira.plugin.s... ] Jeff Mesnil updated WFLY-266: ----------------------------- Fix Version/s: 9.0.0.CR1 > Add Notification support to the domain management API > ----------------------------------------------------- > > Key: WFLY-266 > URL: https://issues.jboss.org/browse/WFLY-266 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Jeff Mesnil > Fix For: 9.0.0.CR1 > > > Management resource should be able to emit notifications; clients can register listeners. -- 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

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3193) upgrade Generic JMS RA to 1.0.4.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3193?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3193: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1082617|https://bugzilla.redhat.com/show_bug.cgi?id=1082617] from NEW to POST > upgrade Generic JMS RA to 1.0.4.Final > ------------------------------------- > > Key: WFLY-3193 > URL: https://issues.jboss.org/browse/WFLY-3193 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: JCA, JMS > Affects Versions: 8.0.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.0.1.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

10 years

1
0
0 / 0

[JBoss JIRA] (JGRP-1734) Probe: restrict requests to certain clusters and/or nodes

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1734?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1734: -------------------------------- Probe requests are actually dropped *at the server side* if the cluster name doesn't match > Probe: restrict requests to certain clusters and/or nodes > --------------------------------------------------------- > > Key: JGRP-1734 > URL: https://issues.jboss.org/browse/JGRP-1734 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Optional > Fix For: 3.4.1, 3.5 > > > Probe.sh broadcasts requests to all reachable nodes in any cluster. The only way to restrict the reach of a probe request is to pass a time-to-live to it, but that's (a) too coarse-grained and (b) doesn't work for TCP. > We should therefore be able to define a list of clusters and a list of nodes to which we want to restrict the request. Both clusters and nodes should be simple regexps. > The filter is sent with the probe request. Nodes which don't pass the filter simply discard the request. > Example: > {noformat} > probe.sh -cluster DrawCluster,cluster-*{noformat} > This restricts the request to the {{DrawCluster}} and any cluster starting with {{cluster-}}. > {noformat} > probe.sh -nodes cluster-* > {noformat} > Sends the request only to nodes with a name starting with {{cluster}}. -- 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

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-460) Eval does not behave as intended

by Fabian Meyer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-460?page=com.atlassian.jira.plugin... ] Fabian Meyer updated DROOLS-460: -------------------------------- Steps to Reproduce: package org.example; import java.util.Date; declare Thing end declare IDProperty subject : Thing object : int end declare StatusEvent @role(event) @timestamp(timestamp) thingId : int timestamp : Date end rule init when then Thing t = new Thing(); insert (t); insert (new IDProperty(t, 1)); insert (new StatusEvent(1, new Date(0))); insert (new StatusEvent(1, new Date(1))); end rule notLast1 when $t : Thing() IDProperty(subject == $t, $id : object) // Constraint $ev : StatusEvent(thingId == $id) exists( // Constraint StatusEvent(this after $ev, $id == thingId) ) then System.out.println("(1) not last " + $ev); end rule notLast2 when $t : Thing() IDProperty(subject == $t, $id : object) // Constraint $ev : StatusEvent(thingId == $id) exists( // Eval StatusEvent(this after $ev, $evId : thingId) and eval($evId == $id) ) then System.out.println("(2) not last " + $ev); end rule notLast3 when $t : Thing() IDProperty(subject == $t, $id : object) // Eval $ev : StatusEvent() eval($ev.getThingId() == $id) exists( // Constraint StatusEvent(this after $ev, $id == thingId) ) then System.out.println("(3) not last " + $ev); end rule notLast4 when $t : Thing() IDProperty(subject == $t, $id : object) // Eval $ev : StatusEvent() eval($ev.getThingId() == $id) exists( // Eval StatusEvent(this after $ev, $evId : thingId) and eval($evId == $id) ) then System.out.println("(4) not last " + $ev); end Output: (1) not last StatusEvent( thingId=1, timestamp=Thu Jan 01 01:00:00 CET 1970 ) (2) not last StatusEvent( thingId=1, timestamp=Thu Jan 01 01:00:00 CET 1970 ) (3) not last StatusEvent( thingId=1, timestamp=Thu Jan 01 01:00:00 CET 1970 ) Rule "notLast4" doesn't fire was: package org.example; import java.util.Date; declare Thing end declare IDProperty subject : Thing object : int end declare StatusEvent @role(event) @timestamp(timestamp) thingId : int timestamp : Date end rule init when then Thing t = new Thing(); insert (t); insert (new IDProperty(t, 1)); insert (new StatusEvent(1, new Date(0))); insert (new StatusEvent(1, new Date(1))); end rule notLast1 when $t : Thing() IDProperty(subject == $t, $id : object) // Constraint $ev : StatusEvent(thingId == $id) exists( // Constraint StatusEvent(this after $ev, $id == thingId) ) then System.out.println("(1) not last " + $ev); end rule notLast2 when $t : Thing() IDProperty(subject == $t, $id : object) // Constraint $ev : StatusEvent(thingId == $id) exists( // Eval StatusEvent(this after $ev, $evId : thingId) and eval($evId == $id) ) then System.out.println("(2) not last " + $ev); end rule notLast3 when $t : Thing() IDProperty(subject == $t, $id : object) // Eval $ev : StatusEvent() eval($ev.getThingId() == $id) exists( // Constraint StatusEvent(this after $ev, $id == thingId) ) then System.out.println("(3) not last " + $ev); end rule notLast4 when $t : Thing() IDProperty(subject == $t, $id : object) // Eval $ev : StatusEvent() eval($ev.getThingId() == $id) exists( // Eval StatusEvent(this after $ev, $evId : thingId) and eval($evId == $id) ) then System.out.println("(4) not last " + $ev); end Output: (1) not last StatusEvent( thingId=1, timestamp=Thu Jan 01 01:00:00 CET 1970 ) (2) not last StatusEvent( thingId=1, timestamp=Thu Jan 01 01:00:00 CET 1970 ) (3) not last StatusEvent( thingId=1, timestamp=Thu Jan 01 01:00:00 CET 1970 ) Rule "notLast4" doesn't fire > Eval does not behave as intended > -------------------------------- > > Key: DROOLS-460 > URL: https://issues.jboss.org/browse/DROOLS-460 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Final > Reporter: Fabian Meyer > Assignee: Mark Proctor > > Under certain conditions, eval does not behave as intended, when nested in a sub-network. -- 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

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-460) Eval does not behave as intended

by Fabian Meyer (JIRA)

Fabian Meyer created DROOLS-460: ----------------------------------- Summary: Eval does not behave as intended Key: DROOLS-460 URL: https://issues.jboss.org/browse/DROOLS-460 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.1.0.Final Reporter: Fabian Meyer Assignee: Mark Proctor Under certain conditions, eval does not behave as intended, when nested in a sub-network. -- 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

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3196) Confusing IllegalStateException: WELD-000340: A request must be associated with the context when mixing JSF/CDI

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3196?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-3196: ------------------------------------ Assignee: Jozef Hartinger (was: Stuart Douglas) > Confusing IllegalStateException: WELD-000340: A request must be associated with the context when mixing JSF/CDI > --------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3196 > URL: https://issues.jboss.org/browse/WFLY-3196 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: CDI / Weld, JSF > Affects Versions: 8.0.0.Final > Environment: [clock-jsf-test 846]$ uname -a > Darwin scotts-imac 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64 > [clock-jsf-test 847]$ java -version > java version "1.8.0" > Java(TM) SE Runtime Environment (build 1.8.0-b132) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode) > Also seen with: > java version "1.7.0_45" > Java(TM) SE Runtime Environment (build 1.7.0_45-b18) > Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) > Reporter: Scott Stark > Assignee: Jozef Hartinger > > I have a simple web app doing injection into a JSF managed bean using @EJB. When the managed bean lifecycle and duration is described using the JSF @ManagedBean and @ApplicationScoped I get a "IllegalStateException: WELD-000340 ..." error when loading the welcome page. The only workaround I have seen is to disable implicit CDI usage, but the web app is using CDI, so that is not appropriate. > The problem seems to be a lack of understanding what is going on between the weld and jsf containers. I understand that the JSF @ManagedBean is deprecated in favor of CDI @Named, but it would be nice if we can provide better feedback when @ManagedBean is used along with CDI. > The following git repo provides a complete test application along with the steps to cause the error as well as how to fix it by only using CDI annotations. > https://github.com/starksm64/clock-jsf-test -- 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

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2949) Cannot get exception as pass-by-reference

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2949?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2949: ----------------------------------------------- Osamu Nagano <onagano(a)redhat.com> changed the Status of [bug 1082880|https://bugzilla.redhat.com/show_bug.cgi?id=1082880] from NEW to POST > Cannot get exception as pass-by-reference > ----------------------------------------- > > Key: WFLY-2949 > URL: https://issues.jboss.org/browse/WFLY-2949 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.Final > Reporter: Osamu Nagano > Assignee: David Lloyd > Fix For: 8.0.1.Final > > > Despite of {{<in-vm-remote-interface-invocation pass-by-value="false"/>}}, an exception is not thrown by reference, which results in {{java.io.NotSerializableException}} if the exception doesn't implement {{Serializable}}. This is a blocker of a large migration project from WebLogic because it throws by reference even if that doesn't implement {{Serializable}}. -- 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

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2949) Cannot get exception as pass-by-reference

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2949?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2949: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1055896, https://bugzilla.redhat.com/show_bug.cgi?id=1082880 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1055896) > Cannot get exception as pass-by-reference > ----------------------------------------- > > Key: WFLY-2949 > URL: https://issues.jboss.org/browse/WFLY-2949 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.Final > Reporter: Osamu Nagano > Assignee: David Lloyd > Fix For: 8.0.1.Final > > > Despite of {{<in-vm-remote-interface-invocation pass-by-value="false"/>}}, an exception is not thrown by reference, which results in {{java.io.NotSerializableException}} if the exception doesn't implement {{Serializable}}. This is a blocker of a large migration project from WebLogic because it throws by reference even if that doesn't implement {{Serializable}}. -- 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

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3196) Confusing IllegalStateException: WELD-000340: A request must be associated with the context when mixing JSF/CDI

by Scott Stark (JIRA)

Scott Stark created WFLY-3196: --------------------------------- Summary: Confusing IllegalStateException: WELD-000340: A request must be associated with the context when mixing JSF/CDI Key: WFLY-3196 URL: https://issues.jboss.org/browse/WFLY-3196 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: CDI / Weld, JSF Affects Versions: 8.0.0.Final Environment: [clock-jsf-test 846]$ uname -a Darwin scotts-imac 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64 [clock-jsf-test 847]$ java -version java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode) Also seen with: java version "1.7.0_45" Java(TM) SE Runtime Environment (build 1.7.0_45-b18) Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) Reporter: Scott Stark Assignee: Stuart Douglas I have a simple web app doing injection into a JSF managed bean using @EJB. When the managed bean lifecycle and duration is described using the JSF @ManagedBean and @ApplicationScoped I get a "IllegalStateException: WELD-000340 ..." error when loading the welcome page. The only workaround I have seen is to disable implicit CDI usage, but the web app is using CDI, so that is not appropriate. The problem seems to be a lack of understanding what is going on between the weld and jsf containers. I understand that the JSF @ManagedBean is deprecated in favor of CDI @Named, but it would be nice if we can provide better feedback when @ManagedBean is used along with CDI. The following git repo provides a complete test application along with the steps to cause the error as well as how to fix it by only using CDI annotations. https://github.com/starksm64/clock-jsf-test -- 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

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2014