[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, 9 months
[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, 9 months
[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, 9 months
[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, 9 months
[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 reopened WFLY-6480:
---------------------------------
> 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, 9 months
[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:
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*+
# 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
> 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
>
> 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, 9 months
[JBoss JIRA] (WFBUILD-14) Conflicting feature pack dependency versions should not be allowed
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFBUILD-14?page=com.atlassian.jira.plugin... ]
Thomas Diesler closed WFBUILD-14.
---------------------------------
Resolution: Won't Fix
[10:24 AM] Thomas Diesler: My dep chain is wildfly-camel => fuse-patch + wildlfy, fuse-patch => wildfly. The versions of wildfly may be different. What should happen?
[10:24 AM] Thomas Diesler: The obvious thing to happen is an error, right?
[10:26 AM] Stuart Douglas: yes
[10:26 AM] Thomas Diesler: Another option is that the higher version of wildfly is used, if both are version compatible
[10:26 AM] Stuart Douglas: we don't know what is compatible
[10:26 AM] Stuart Douglas: error is the only this that really makes sense
[10:26 AM] Stuart Douglas: @AlexeyLoubyansky is actually working on version two of this
[10:27 AM] Stuart Douglas: so it is unlikely that there is going to be any big changes in the current code base
[10:27 AM] Thomas Diesler: Yep, I would agree. In that case this issue is reduced to a "does not fail" thing, which can be resolved as "won't fix"
https://github.com/stuartwdouglas/wildfly-provisioning/blob/master/docs/s...
> Conflicting feature pack dependency versions should not be allowed
> ------------------------------------------------------------------
>
> Key: WFBUILD-14
> URL: https://issues.jboss.org/browse/WFBUILD-14
> Project: WildFly Build Tools
> Issue Type: Bug
> Reporter: James Netherton
> Assignee: Stuart Douglas
> Fix For: 1.1.7.Final
>
>
> There was a brief discussion about this on the WildFly dev mailing list so I'm capturing the problem here as well.
> Consider the following.
> Feature pack 'A' has a dependency on the WildFly 9 feature pack. E.g:
> {code:xml}
> <dependencies>
> <artifact name="org.wildfly:wildfly-feature-pack:9.0.1.Final" />
> </dependencies>
> {code}
> Feature pack 'B' has a dependency on the WildFly 10 feature pack and also on feature pack 'A'. E.g:
> {code:xml}
> <dependencies>
> <artifact name="org.wildfly:wildfly-feature-pack:10.0.0.CR3" />
> <artifact name="org.foo:feature-pack-A" />
> </dependencies>
> {code}
> The result is that you'll have overlapping and possibly problematic non-overlapping file paths coming from the conflicting WildFly versions
> At the moment the plugins allow this scenario, which can lead to all sorts of horrors when using the server-provisioning plugin to provision an app server.
> CrossRef: https://github.com/wildfly-extras/fuse-patch/issues/101
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1243) ClassCastException at runtime when trying to match "from" and a built-in accumulate function.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1243?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1243:
-------------------------------------
Also this commit is necessary https://github.com/droolsjbpm/drools/commit/049a67a78
> ClassCastException at runtime when trying to match "from" and a built-in accumulate function.
> ---------------------------------------------------------------------------------------------
>
> Key: DROOLS-1243
> URL: https://issues.jboss.org/browse/DROOLS-1243
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Priority: Minor
> Fix For: 7.0.0.Beta2
>
>
> A rule like this
> {code:java}
> global java.util.List list;
> rule R when
> $theFrom : Double() from accumulate(MyPerson( $val : age );
> sum( $val ) )
> then
> list.add($theFrom);
> end
> {code}
> works fine but if modified like:
> {code:java}
> import java.math.BigDecimal;
> global java.util.List list;
> rule R when
> $theFrom : BigDecimal() from accumulate(MyPerson( $val : age );
> sum( $val ) )
> then
> list.add($theFrom);
> end
> {code}
> then it breaks at runtime, with {{ClassCastException}}.
> Suggested correct behavior:
> {quote}it should either raise a compilation error (if it is a typed function, like sum()) or just fail to match at runtime, as BigDecimal() does not match the result of sum(){quote}
> full stack trace for reference:
> {code:java}
> Exception executing consequence for rule "R" in defaultpkg: java.lang.ClassCastException: java.lang.Double cannot be cast to java.math.BigDecimal
> at org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
> at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1110)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:121)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1360)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1298)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1353)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1344)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1325)
> at org.drools.compiler.integrationtests.AccumulateTest.testCCEAtRuntimeFromAccumulate(AccumulateTest.java:3116)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: java.lang.ClassCastException: java.lang.Double cannot be cast to java.math.BigDecimal
> at defaultpkg.Rule_R880096074DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> at defaultpkg.Rule_R880096074DefaultConsequenceInvoker.evaluate(Unknown Source)
> at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1099)
> ... 32 more
> {code}
> Will submit test case for reproducing the error.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6914) Description of binding-type for rebind operation should not include external-context type
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6914?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved JBEAP-5517 to WFLY-6914:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6914 (was: JBEAP-5517)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Naming
(was: Naming)
Affects Version/s: (was: 7.1.0.DR1)
> Description of binding-type for rebind operation should not include external-context type
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-6914
> URL: https://issues.jboss.org/browse/WFLY-6914
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Minor
>
> naming/src/main/resources/org/jboss/as/naming/subsystem/LocalDescriptions.properties:
> {code}
> binding.rebind.binding-type=The type of binding to create, may be simple, lookup, external-context or object-factory
> {code}
> The {{external-context}} binding cannot be used for {{rebind}} operation. I'd suggest removing it from the operation description.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6913) RebindTestCase does not remove all created bindings
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6913?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved JBEAP-5516 to WFLY-6913:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6913 (was: JBEAP-5516)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Naming
(was: Naming)
Affects Version/s: (was: 7.1.0.DR1)
> RebindTestCase does not remove all created bindings
> ---------------------------------------------------
>
> Key: WFLY-6913
> URL: https://issues.jboss.org/browse/WFLY-6913
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
>
> {{org.jboss.as.test.integration.naming.RebindTestCase}} creates 2 bindings but removes only one of them at the end of the test. I'd suggest removing all created bindings.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months