August 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1691) Upgrade to Remoting JMX 3.0.0.Alpha1

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-1691: ---------------------------------------- Summary: Upgrade to Remoting JMX 3.0.0.Alpha1 Key: WFCORE-1691 URL: https://issues.jboss.org/browse/WFCORE-1691 Project: WildFly Core Issue Type: Component Upgrade Components: JMX Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha5 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-113) Release Remoting JMX 3.0.0.Alpha1

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-113?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved REMJMX-113. ------------------------------------- Resolution: Done > Release Remoting JMX 3.0.0.Alpha1 > --------------------------------- > > Key: REMJMX-113 > URL: https://issues.jboss.org/browse/REMJMX-113 > Project: Remoting JMX > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-109) Move from jboss-sasl to Elytron backed security

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-109?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved REMJMX-109. ------------------------------------- Resolution: Done > Move from jboss-sasl to Elytron backed security > ----------------------------------------------- > > Key: REMJMX-109 > URL: https://issues.jboss.org/browse/REMJMX-109 > Project: Remoting JMX > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-108) Switch to Remoting 5

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-108?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved REMJMX-108. ------------------------------------- Resolution: Done > Switch to Remoting 5 > -------------------- > > Key: REMJMX-108 > URL: https://issues.jboss.org/browse/REMJMX-108 > Project: Remoting JMX > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-113) Release Remoting JMX 3.0.0.Alpha1

by Darran Lofthouse (JIRA)

Darran Lofthouse created REMJMX-113: --------------------------------------- Summary: Release Remoting JMX 3.0.0.Alpha1 Key: REMJMX-113 URL: https://issues.jboss.org/browse/REMJMX-113 Project: Remoting JMX Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1245) Document limitation of (legacy) Accumulate CE Alternate Syntax: single function with return type

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1245?page=com.atlassian.jira.plugi... ] Matteo Mortari commented on DROOLS-1245: ---------------------------------------- Changed the main description to reflect latest changes (compile-time check also when accumulate function returns an iterable/collection). > Document limitation of (legacy) Accumulate CE Alternate Syntax: single function with return type > ------------------------------------------------------------------------------------------------ > > Key: DROOLS-1245 > URL: https://issues.jboss.org/browse/DROOLS-1245 > Project: Drools > Issue Type: Enhancement > Components: docs > Affects Versions: 6.4.0.Final > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > Document limitations and common pitfalls: > h2. from+accumulate does not iterate > This does NOT iterate over the elements of the accumulate function: > {code:java} > rule R when > $theFrom : Object() from accumulate(MyPerson( $val : name ); > collectList( $val ) ) > then > list.add($theFrom); > end > {code} > and in fact the binded $theFrom : Object() is the List returned by the collect list. > While normally the "from" iterates over the element of list/iterable collections. > {code:java} > rule R1 when > $list : List( ) > $s : Integer() from $list > then > out.add($s); > end > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1245) Document limitation of (legacy) Accumulate CE Alternate Syntax: single function with return type

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1245?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1245: ----------------------------------- Description: Document limitations and common pitfalls: h2. from+accumulate does not iterate This does NOT iterate over the elements of the accumulate function: {code:java} rule R when $theFrom : Object() from accumulate(MyPerson( $val : name ); collectList( $val ) ) then list.add($theFrom); end {code} and in fact the binded $theFrom : Object() is the List returned by the collect list. While normally the "from" iterates over the element of list/iterable collections. {code:java} rule R1 when $list : List( ) $s : Integer() from $list then out.add($s); end {code} was: Document limitations and common pitfalls: h2. from+accumulate does not iterate This does NOT iterate over the elements of the accumulate function: {code:java} rule R when $theFrom : Object() from accumulate(MyPerson( $val : name ); collectList( $val ) ) then list.add($theFrom); end {code} and in fact the binded $theFrom : Object() is the List returned by the collect list. While normally the "from" iterates over the element of list/iterable collections. {code:java} rule R1 when $list : List( ) $s : Integer() from $list then out.add($s); end {code} h2. limited scope of compile-time checks Compile-time checks are performed for Accumulate Functions returning a single result. Compile-time checks are NOT performed for iterable Accumulate Functions, the case when the accumulate function returns a collection. With ref to DROOLS-1243. For instance this fails at compilation: {code:java} rule R when $theFrom : BigDecimal() from accumulate(MyPerson( $val : age ); sum( $val ) ) then list.add($theFrom); end {code} but the following does passes compilation: {code:java} rule R when $theFrom : String() from accumulate(MyPerson( $val : name ); collectList( $val ) ) then list.add($theFrom); end {code} only to fail later at runtime with CCE: {code:java} Caused by: java.lang.ClassCastException: java.util.Collections$UnmodifiableRandomAccessList cannot be cast to java.lang.String {code} > Document limitation of (legacy) Accumulate CE Alternate Syntax: single function with return type > ------------------------------------------------------------------------------------------------ > > Key: DROOLS-1245 > URL: https://issues.jboss.org/browse/DROOLS-1245 > Project: Drools > Issue Type: Enhancement > Components: docs > Affects Versions: 6.4.0.Final > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > Document limitations and common pitfalls: > h2. from+accumulate does not iterate > This does NOT iterate over the elements of the accumulate function: > {code:java} > rule R when > $theFrom : Object() from accumulate(MyPerson( $val : name ); > collectList( $val ) ) > then > list.add($theFrom); > end > {code} > and in fact the binded $theFrom : Object() is the List returned by the collect list. > While normally the "from" iterates over the element of list/iterable collections. > {code:java} > rule R1 when > $list : List( ) > $s : Integer() from $list > then > out.add($s); > end > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1673) Testsuite: tests for CLI controller aliases

by Martin Schvarcbacher (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1673?page=com.atlassian.jira.plugi... ] Martin Schvarcbacher updated WFCORE-1673: ----------------------------------------- Description: *Description:* Test plan to add integration tests for "use-legacy-override", behavior of default-controller and default-protocol defined in jboss-cli.xml when connecting to a server. Additionally test that the correct port is used according to specified protocol when no port is explicitly specified. Added integration tests for server aliases defined in jboss-cli.xml Usage in bin/jboss-cli.xml: {code:xml} <controllers> <controller name="ServerOne"> <protocol>http-remoting</protocol> <host>localhost</host> <port>9990</port> </controller> </controllers> {code} {code:bash} ./bin/jboss-cli.sh --controller=ServerOne --connect {code} +*TEST PLAN for controller aliases*+ # set invalid default controller configuration to ensure all settings are being loaded only from controller aliases # connect to controller alias with all options (protocol, hostname, port) specified # protocol specified in <default-controller> overrides <default-protocol> when calling --connect without --controller # empty jboss-cli.xml configuration uses implicit settings for both default controller and controller alias *+TEST PLAN for use-legacy-override+* {code:shell} ./bin/jboss-cli.[sh/bat] --connect [--controller=localhost:$TESTED_PORT] {code} * <default-protocol use-legacy-override=true> && no protocol specified && port=9999 → use remoting:// * <default-protocol use-legacy-override=false> && no protocol specified && port=9999 → use protocol from <default-protocol> * no protocol specified in <default-controller> → use <default-protocol> * <default-protocol> is overridden by protocol defined in <default-controller> (JBEAP 7.0.0 new element) was: Added integration tests for server aliases defined in jboss-cli.xml Usage in bin/jboss-cli.xml: {code:xml} <controllers> <controller name="ServerOne"> <protocol>http-remoting</protocol> <host>localhost</host> <port>9990</port> </controller> </controllers> {code} {code:bash} ./bin/jboss-cli.sh --controller=ServerOne --connect {code} +*TEST PLAN for controller aliases*+ # set invalid default controller configuration to ensure all settings are being loaded only from controller aliases # connect to controller alias with all options (protocol, hostname, port) specified # protocol specified in <default-controller> overrides <default-protocol> when calling --connect without --controller # empty jboss-cli.xml configuration uses implicit settings for both default controller and controller alias *+TEST PLAN for use-legacy-override+* {code:shell} ./bin/jboss-cli.[sh/bat] --connect [--controller=localhost:$TESTED_PORT] {code} * <default-protocol use-legacy-override=true> && no protocol specified && port=9999 → use remoting:// * <default-protocol use-legacy-override=false> && no protocol specified && port=9999 → use protocol from <default-protocol> * no protocol specified in <default-controller> → use <default-protocol> * <default-protocol> is overridden by protocol defined in <default-controller> (JBEAP 7.0.0 new element) > Testsuite: tests for CLI controller aliases > ------------------------------------------- > > Key: WFCORE-1673 > URL: https://issues.jboss.org/browse/WFCORE-1673 > Project: WildFly Core > Issue Type: Task > Components: CLI, Test Suite > Reporter: Martin Schvarcbacher > Assignee: Martin Schvarcbacher > Priority: Minor > > *Description:* > Test plan to add integration tests for "use-legacy-override", behavior of default-controller and default-protocol defined in jboss-cli.xml when connecting to a server. Additionally test that the correct port is used according to specified protocol when no port is explicitly specified. > Added integration tests for server aliases defined in jboss-cli.xml > Usage in bin/jboss-cli.xml: > {code:xml} > <controllers> > <controller name="ServerOne"> > <protocol>http-remoting</protocol> > <host>localhost</host> > <port>9990</port> > </controller> > </controllers> > {code} > {code:bash} > ./bin/jboss-cli.sh --controller=ServerOne --connect > {code} > +*TEST PLAN for controller aliases*+ > # set invalid default controller configuration to ensure all settings are being loaded only from controller aliases > # connect to controller alias with all options (protocol, hostname, port) specified > # protocol specified in <default-controller> overrides <default-protocol> when calling --connect without --controller > # empty jboss-cli.xml configuration uses implicit settings for both default controller and controller alias > *+TEST PLAN for use-legacy-override+* > {code:shell} > ./bin/jboss-cli.[sh/bat] --connect [--controller=localhost:$TESTED_PORT] > {code} > * <default-protocol use-legacy-override=true> && no protocol specified && port=9999 → use remoting:// > * <default-protocol use-legacy-override=false> && no protocol specified && port=9999 → use protocol from <default-protocol> > * no protocol specified in <default-controller> → use <default-protocol> > * <default-protocol> is overridden by protocol defined in <default-controller> (JBEAP 7.0.0 new element) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1690) Tab completion for echo-dmr command is broken

by Petr Kremensky (JIRA)

Petr Kremensky created WFCORE-1690: -------------------------------------- Summary: Tab completion for echo-dmr command is broken Key: WFCORE-1690 URL: https://issues.jboss.org/browse/WFCORE-1690 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Petr Kremensky Assignee: Jean-Francois Denise Tab completion for echo-dmr command doesn't work. To reproduce, start the standalone server and connect with CLI *actual 3.0.0.Alpha5-SNAPSHOT 77673c5* {noformat} [standalone@localhost:9990 /] echo-dmr /sub[TAB] core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB] core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property {noformat} *expected* {noformat} [standalone@localhost:9990 /] echo-dmr /sub[TAB] [standalone@localhost:9990 /] echo-dmr /subsystem= [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB] [standalone@localhost:9990 /] echo-dmr /subsystem=logging {noformat} The issue is not reproducible with 2.2.0.CR7 (EAP 7.1.0.DR1). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6480) JNDIBindingMBeanTestCase misses JndiPermission when run with security manager

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-6480?page=com.atlassian.jira.plugin.... ] Ivo Studensky updated WFLY-6480: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/8869, https://github.com/wildfly/wildfly/pull/9098 (was: https://github.com/wildfly/wildfly/pull/8869) > JNDIBindingMBeanTestCase misses JndiPermission when run with security manager > ----------------------------------------------------------------------------- > > Key: WFLY-6480 > URL: https://issues.jboss.org/browse/WFLY-6480 > Project: WildFly > Issue Type: Bug > Reporter: Jan Tymel > Assignee: Ivo Studensky > Fix For: 10.1.0.CR1 > > > *JNDIBindingMBeanTestCase* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.sar.JNDIBindingMBeanTestCase -Dsecurity.manager}} > Fails with: > {code} > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.naming.java.permission.JndiPermission" "global/env/foo/legacy2" "bind")" in code source "(vfs:/content/multiple-jndi-binding-mbeans.sar <no signer certificates>)" of "null") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) > at org.jboss.as.naming.NamingContext.check(NamingContext.java:591) > at org.jboss.as.naming.NamingContext.bind(NamingContext.java:251) > at org.jboss.as.naming.InitialContext$DefaultInitialContext.bind(InitialContext.java:264) > at org.jboss.as.naming.NamingContext.bind(NamingContext.java:289) > at javax.naming.InitialContext.bind(InitialContext.java:425) > at javax.naming.InitialContext.bind(InitialContext.java:425) > at org.jboss.as.test.integration.sar.JNDIBindingService.start(JNDIBindingService.java:53) > ... 12 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2016