October 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-626) collectList on objects of type java.lang.Class get returned as null

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-626?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-626. -------------------------------- Labels: backport-to-6.0.x (was: ) Fix Version/s: 6.2.0.CR1 Resolution: Done Fixed by https://github.com/droolsjbpm/drools/commit/4458fd09f > collectList on objects of type java.lang.Class get returned as null > ------------------------------------------------------------------- > > Key: DROOLS-626 > URL: https://issues.jboss.org/browse/DROOLS-626 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta1 > Environment: Snapshot Drools 6.2.0.201410031437 runtime > Reporter: David Fell > Assignee: Mario Fusco > Labels: backport-to-6.0.x > Fix For: 6.2.0.CR1 > > > If collectList in an accumulate is supplied objects of type java.lang.Class, then subsequent examination of the supplied list yields null values rather than the expect Class values. > Test case below. Swapping the comments to make InitClass have a String field instead of a Class field changes the behaviour of the list from collectList to what one would expect. > package com.sample > declare MyClass end > declare InitClass > clazz: Class @key > // clazz: String @key > end > rule "init" > when > then > insert( new InitClass( MyClass.class ) ); > // insert( new InitClass( "some string" ) ); > end > rule "make init classes" > when > accumulate( InitClass( $clazz; ), $list: collectList( $clazz ) ) > then > System.out.printf("%d items in list\n", $list.size()); > for(Object obj : $list) > System.out.printf("item is %s\n", obj); > end > rule "show init classes" > when > InitClass( $v; ) > then > System.out.printf("match %s\n", $v); > end -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-626) collectList on objects of type java.lang.Class get returned as null

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-626?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-626: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > collectList on objects of type java.lang.Class get returned as null > ------------------------------------------------------------------- > > Key: DROOLS-626 > URL: https://issues.jboss.org/browse/DROOLS-626 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta1 > Environment: Snapshot Drools 6.2.0.201410031437 runtime > Reporter: David Fell > Assignee: Mario Fusco > > If collectList in an accumulate is supplied objects of type java.lang.Class, then subsequent examination of the supplied list yields null values rather than the expect Class values. > Test case below. Swapping the comments to make InitClass have a String field instead of a Class field changes the behaviour of the list from collectList to what one would expect. > package com.sample > declare MyClass end > declare InitClass > clazz: Class @key > // clazz: String @key > end > rule "init" > when > then > insert( new InitClass( MyClass.class ) ); > // insert( new InitClass( "some string" ) ); > end > rule "make init classes" > when > accumulate( InitClass( $clazz; ), $list: collectList( $clazz ) ) > then > System.out.printf("%d items in list\n", $list.size()); > for(Object obj : $list) > System.out.printf("item is %s\n", obj); > end > rule "show init classes" > when > InitClass( $v; ) > then > System.out.printf("match %s\n", $v); > end -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-149) Failues in 'resolve-expression" op appear in server log

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-149?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-149: ----------------------------------------- My theory about the logging happening because a cause was attached is incorrect. It's logged because it happens at Stage.RUNTIME. RUNTIME OFEs are logged as there is the potential they have disrupted the server. Solution is to not throw the OFE but rather to use context.getFailureDescription() to report the failure to the client. > Failues in 'resolve-expression" op appear in server log > ------------------------------------------------------- > > Key: WFCORE-149 > URL: https://issues.jboss.org/browse/WFCORE-149 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Priority: Minor > > I happened to notice this in a server log: > 11:53:48,854 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("resolve-expression") failed - address: ([]) - failure description: "WFLYCTL0211: Cannot resolve expression 'expression \"${unresolvable}\"' -- java.lang.IllegalStateException: Failed to resolve expression: ${unresolvable}" > That failure shouldn't end up in the server log; it's just a client mistake unrelated to server operation. > A guess is that it's logged because the OFE has the ISE attached as a cause, in which case a simple fix is to not attach the ISE, which adds no value. > Note the handler has a catch block above the one that throws this OFE that handles a SecurityException case. In that case it *may* be appropriate for something to appear in the logs, assuming tracing how the SE can happen indicates it could be triggered by a user fishing for an exploit. In that case a direct WARN in the log from the ResolveExpressionHandler instead of attaching the SE to the OFE and letting the OperationContext log an ERROR may be more appropriate. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-149) Failues in 'resolve-expression" op appear in server log

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-149: --------------------------------------- Summary: Failues in 'resolve-expression" op appear in server log Key: WFCORE-149 URL: https://issues.jboss.org/browse/WFCORE-149 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Priority: Minor I happened to notice this in a server log: 11:53:48,854 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("resolve-expression") failed - address: ([]) - failure description: "WFLYCTL0211: Cannot resolve expression 'expression \"${unresolvable}\"' -- java.lang.IllegalStateException: Failed to resolve expression: ${unresolvable}" That failure shouldn't end up in the server log; it's just a client mistake unrelated to server operation. A guess is that it's logged because the OFE has the ISE attached as a cause, in which case a simple fix is to not attach the ISE, which adds no value. Note the handler has a catch block above the one that throws this OFE that handles a SecurityException case. In that case it *may* be appropriate for something to appear in the logs, assuming tracing how the SE can happen indicates it could be triggered by a user fishing for an exploit. In that case a direct WARN in the log from the ResolveExpressionHandler instead of attaching the SE to the OFE and letting the OperationContext log an ERROR may be more appropriate. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-623) Rule with NOT causes excessive firing of the rule

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-623?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-623. -------------------------------- Labels: backport-to-6.0.x (was: ) Fix Version/s: 6.2.0.CR1 Resolution: Done Fixed by https://github.com/droolsjbpm/drools/commit/35bb5112d > Rule with NOT causes excessive firing of the rule > ------------------------------------------------- > > Key: DROOLS-623 > URL: https://issues.jboss.org/browse/DROOLS-623 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.Beta1 > Reporter: Anantjot Anand > Assignee: Mario Fusco > Labels: backport-to-6.0.x > Fix For: 6.2.0.CR1 > > Attachments: TestNotSubnetworkIssue.java > > > Debugging of the issue points to De-Activation not able to happen due to RuleExecutor not set dirty upon the call made to BetaNode [line: 369] - doDeleteRightTuple(RightTuple, InternalWorkingMemory, BetaMemory) during reEvaluateNetwork after first time fire of the rule. Further drilling into doDeleteRightTuple indicates memory.unlinkNode(wm) call fails in > PathMemory.unlinkedSegment as it finds the isRuleLinked() to be false. > if (linkedRule && !isRuleLinked()) { > doUnlinkRule(wm); > } > Please see the attached junit test case reproducing the issue. There are two rules R1 and R2. R1 sets up criteria needed by R2. > There are two changes that make this issue not appear. > 1) Setting the value required by (inside the NOT clause) rule before calling fireAllRules. > 2) Removing the NOT clause from R2. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3937) Jackson libs are Private, should be Public

by Marek Novotny (JIRA)

[ https://issues.jboss.org/browse/WFLY-3937?page=com.atlassian.jira.plugin.... ] Marek Novotny moved JBEAP-87 to WFLY-3937: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-3937 (was: JBEAP-87) Workflow: GIT Pull Request workflow (was: classic default workflow) > Jackson libs are Private, should be Public > ------------------------------------------ > > Key: WFLY-3937 > URL: https://issues.jboss.org/browse/WFLY-3937 > Project: WildFly > Issue Type: Bug > Environment: EAP 6.3.0.ER2 > Reporter: Marek Novotny > > The following libraries have their module.xml files set to *private*: > * org.codehaus.jackson.jackson-core-asl > * org.codehaus.jackson.jackson-mapper-asl > * org.codehaus.jackson.jackson-jaxrs > * org.codehaus.jackson.jackson-xc > After talking with [~bill.burke], these should be *public*. > While these modules are private, the use of them creates WARNings in the stack trace. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-623) Rule with NOT causes excessive firing of the rule

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-623?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-623: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Rule with NOT causes excessive firing of the rule > ------------------------------------------------- > > Key: DROOLS-623 > URL: https://issues.jboss.org/browse/DROOLS-623 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.Beta1 > Reporter: Anantjot Anand > Assignee: Mario Fusco > Attachments: TestNotSubnetworkIssue.java > > > Debugging of the issue points to De-Activation not able to happen due to RuleExecutor not set dirty upon the call made to BetaNode [line: 369] - doDeleteRightTuple(RightTuple, InternalWorkingMemory, BetaMemory) during reEvaluateNetwork after first time fire of the rule. Further drilling into doDeleteRightTuple indicates memory.unlinkNode(wm) call fails in > PathMemory.unlinkedSegment as it finds the isRuleLinked() to be false. > if (linkedRule && !isRuleLinked()) { > doUnlinkRule(wm); > } > Please see the attached junit test case reproducing the issue. There are two rules R1 and R2. R1 sets up criteria needed by R2. > There are two changes that make this issue not appear. > 1) Setting the value required by (inside the NOT clause) rule before calling fireAllRules. > 2) Removing the NOT clause from R2. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2879) Remove duplicated code from test cases where custom modules are needed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2879?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2879: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1147391|https://bugzilla.redhat.com/show_bug.cgi?id=1147391] from ASSIGNED to CLOSED > Remove duplicated code from test cases where custom modules are needed > ---------------------------------------------------------------------- > > Key: WFLY-2879 > URL: https://issues.jboss.org/browse/WFLY-2879 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 8.1.0.Final > Reporter: Pedro Igor > Assignee: Pedro Igor > > When writing some integration tests for the PicketLink subsystem, I've noticed that there is no utility class or API to make easier create and remove custom modules from the modules directory. > There are a few tests with this requirement, and most of them are replicating code. > After discussing with [~kabirkhan], he suggested to open this JIRA to review those test cases and make them use a reusable component to work with custom modules. > I've already wrote a class that I think can satisfy all test cases requiring a custom module. > See https://github.com/pedroigor/wildfly/blob/WFLY-2733/testsuite/integration.... > Usage example: https://github.com/pedroigor/wildfly/blob/WFLY-2733/testsuite/integration... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-129) Overlay does not work for subunits in exploded deployments.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-129?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-129: ------------------------------------------------ mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1147353|https://bugzilla.redhat.com/show_bug.cgi?id=1147353] from NEW to CLOSED > Overlay does not work for subunits in exploded deployments. > ----------------------------------------------------------- > > Key: WFCORE-129 > URL: https://issues.jboss.org/browse/WFCORE-129 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha8 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 1.0.0.Alpha9 > > > If deployment is exploded and has subdeployments overlay wont work on files contained in said subdeployments. > Reproducers: https://github.com/baranowb/wildfly/tree/WFCORE-83-TESTS -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 1139197|https://bugzilla.redhat.com/show_bug.cgi?id=1139197] from ASSIGNED to MODIFIED > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

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 October 2014