June 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4138) Building a KJAR using Decision Table Templates throws NPE

by Carl Mes (Jira)

[ https://issues.jboss.org/browse/DROOLS-4138?page=com.atlassian.jira.plugi... ] Carl Mes updated DROOLS-4138: ----------------------------- Description: Steps to building a new KJar by defining Resource objects and adding then using KieFileSystem.write(), if a Decision Table Template resource type is added then we get a null pointer exception when the KieBuilder.buildAll() method is invoked. Sample code that demonstrates this error can be found here: https://github.com/carlmes/decision-table-template, specifically the notes in [TestDecisionTableBuild.java|https://github.com/carlmes/decision-table-tem...]. Red Hat support case: https://access.redhat.com/support/cases/#/case/02397413 I have created a proposed fix in [DecisionTableConfigurationImpl.java|https://github.com/kiegroup/drools/bl...], by implementing the missing properties in the fromProperties and toProperties methods. Please see attached updated file that has been tested to fix the issue locally. was: Steps to building a new KJar by defining Resource objects and adding then using KieFileSystem.write(), if a Decision Table Template resource type is added then we get a null pointer exception when the KieBuilder.buildAll() method is invoked. Sample code that demonstrates this error can be found here: https://github.com/carlmes/decision-table-template Red Hat support case: https://access.redhat.com/support/cases/#/case/02397413 I have created a proposed fix in [DecisionTableConfigurationImpl.java|https://github.com/kiegroup/drools/bl...], by implementing the missing properties in the fromProperties and toProperties methods. Please see attached updated file that has been tested to fix the issue locally. > Building a KJAR using Decision Table Templates throws NPE > --------------------------------------------------------- > > Key: DROOLS-4138 > URL: https://issues.jboss.org/browse/DROOLS-4138 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.18.0.Final, 7.23.0.Final > Reporter: Carl Mes > Assignee: Mario Fusco > Priority: Major > Attachments: DecisionTableConfigurationImpl.java > > > Steps to building a new KJar by defining Resource objects and adding then using KieFileSystem.write(), if a Decision Table Template resource type is added then we get a null pointer exception when the KieBuilder.buildAll() method is invoked. > Sample code that demonstrates this error can be found here: https://github.com/carlmes/decision-table-template, specifically the notes in [TestDecisionTableBuild.java|https://github.com/carlmes/decision-table-tem...]. > Red Hat support case: https://access.redhat.com/support/cases/#/case/02397413 > I have created a proposed fix in [DecisionTableConfigurationImpl.java|https://github.com/kiegroup/drools/bl...], by implementing the missing properties in the fromProperties and toProperties methods. Please see attached updated file that has been tested to fix the issue locally. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4138) Building a KJAR using Decision Table Templates throws NPE

by Carl Mes (Jira)

[ https://issues.jboss.org/browse/DROOLS-4138?page=com.atlassian.jira.plugi... ] Carl Mes updated DROOLS-4138: ----------------------------- Description: Steps to building a new KJar by defining Resource objects and adding then using KieFileSystem.write(), if a Decision Table Template resource type is added then we get a null pointer exception when the KieBuilder.buildAll() method is invoked. Sample code that demonstrates this error can be found here: https://github.com/carlmes/decision-table-template Red Hat support case: https://access.redhat.com/support/cases/#/case/02397413 I have created a proposed fix in [DecisionTableConfigurationImpl.java|https://github.com/kiegroup/drools/bl...], by implementing the missing properties in the fromProperties and toProperties methods. Please see attached updated file that has been tested to fix the issue locally. was: Steps to building a new KJar by defining Resource objects and adding then using KieFileSystem.write(), if a Decision Table Template resource type is added then we get a null pointer exception when the KieBuilder.buildAll() method is invoked. Sample code that demonstrates this error can be found here: https://github.com/carlmes/decision-table-template Red Hat support case: https://access.redhat.com/support/cases/#/case/02397413 > Building a KJAR using Decision Table Templates throws NPE > --------------------------------------------------------- > > Key: DROOLS-4138 > URL: https://issues.jboss.org/browse/DROOLS-4138 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.18.0.Final, 7.23.0.Final > Reporter: Carl Mes > Assignee: Mario Fusco > Priority: Major > Attachments: DecisionTableConfigurationImpl.java > > > Steps to building a new KJar by defining Resource objects and adding then using KieFileSystem.write(), if a Decision Table Template resource type is added then we get a null pointer exception when the KieBuilder.buildAll() method is invoked. > Sample code that demonstrates this error can be found here: https://github.com/carlmes/decision-table-template > Red Hat support case: https://access.redhat.com/support/cases/#/case/02397413 > I have created a proposed fix in [DecisionTableConfigurationImpl.java|https://github.com/kiegroup/drools/bl...], by implementing the missing properties in the fromProperties and toProperties methods. Please see attached updated file that has been tested to fix the issue locally. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4138) Building a KJAR using Decision Table Templates throws NPE

by Carl Mes (Jira)

[ https://issues.jboss.org/browse/DROOLS-4138?page=com.atlassian.jira.plugi... ] Carl Mes updated DROOLS-4138: ----------------------------- Attachment: DecisionTableConfigurationImpl.java > Building a KJAR using Decision Table Templates throws NPE > --------------------------------------------------------- > > Key: DROOLS-4138 > URL: https://issues.jboss.org/browse/DROOLS-4138 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.18.0.Final, 7.23.0.Final > Reporter: Carl Mes > Assignee: Mario Fusco > Priority: Major > Attachments: DecisionTableConfigurationImpl.java > > > Steps to building a new KJar by defining Resource objects and adding then using KieFileSystem.write(), if a Decision Table Template resource type is added then we get a null pointer exception when the KieBuilder.buildAll() method is invoked. > Sample code that demonstrates this error can be found here: https://github.com/carlmes/decision-table-template > Red Hat support case: https://access.redhat.com/support/cases/#/case/02397413 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4138) Building a KJAR using Decision Table Templates throws NPE

by Carl Mes (Jira)

Carl Mes created DROOLS-4138: -------------------------------- Summary: Building a KJAR using Decision Table Templates throws NPE Key: DROOLS-4138 URL: https://issues.jboss.org/browse/DROOLS-4138 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.23.0.Final, 7.18.0.Final Reporter: Carl Mes Assignee: Mario Fusco Steps to building a new KJar by defining Resource objects and adding then using KieFileSystem.write(), if a Decision Table Template resource type is added then we get a null pointer exception when the KieBuilder.buildAll() method is invoked. Sample code that demonstrates this error can be found here: https://github.com/carlmes/decision-table-template Red Hat support case: https://access.redhat.com/support/cases/#/case/02397413 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2350) TCP: connection close can block when send() block on full TCP send-window

by David Stephan (Jira)

[ https://issues.jboss.org/browse/JGRP-2350?page=com.atlassian.jira.plugin.... ] David Stephan reassigned JGRP-2350: ----------------------------------- Assignee: Bela Ban (was: David Stephan) > TCP: connection close can block when send() block on full TCP send-window > ------------------------------------------------------------------------- > > Key: JGRP-2350 > URL: https://issues.jboss.org/browse/JGRP-2350 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.1 > > > When a peer is non-responsive (without closing its socket), a TcpConnection.send() can block on a write (state is RUNNABLE!). > The problem is that the TcpConnection cannout be closed either, as TcpConnection.close() tries to acquire the same lock already held by TcpConnection.send(). > See the stack trace below for a sample scenario. > The use case is this one: > * Say we have nodes A (coord), B and C > * There's heavy (clustering) traffic to all 3 nodes, from the 2 clients > * B is isolated by executing 'ifdown bond0' > * At this point, the messages going to B will back up at (say) A because A doesn't get any TCP acks from B > * At some point, depending on the traffic and the size of the sent messages, A will acquire a lock on the send connection to B, to write data, but the write will block as the TCP send-window to B is full (note that the sender thread will still be in state RUNNABLE!) > * After 40s, A suspects B and emits a new view {A,C} > * This causes A's connection to B to be closed and subsequently removed. However, this _won't_ happen, as the connection close will need to acquire the connection lock, which is held by the TCP write > {noformat} > "main" #1 prio=5 os_prio=31 tid=0x00007fbbd3802000 nid=0x2303 runnable [0x0000700009793000] > java.lang.Thread.State: RUNNABLE > at java.net.SocketOutputStream.socketWrite0(Native Method) > at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111) > at java.net.SocketOutputStream.write(SocketOutputStream.java:155) > at java.io.BufferedOutputStream.write(BufferedOutputStream.java:122) > - locked <0x000000079e790a50> (a java.io.BufferedOutputStream) > at java.io.DataOutputStream.write(DataOutputStream.java:107) > - locked <0x000000079e790838> (a java.io.DataOutputStream) > at org.jgroups.blocks.cs.TcpConnection.doSend(TcpConnection.java:161) > at org.jgroups.blocks.cs.TcpConnection.send(TcpConnection.java:131) > at org.jgroups.blocks.cs.TcpClient.send(TcpClient.java:103) > at org.jgroups.tests.bla6.main(bla6.java:35) > "Thread-2" #15 prio=5 os_prio=31 tid=0x00007fbbd2150800 nid=0x6503 waiting on condition [0x000070000bcf6000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x000000079e7871a8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) > at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) > at org.jgroups.blocks.cs.TcpConnection.close(TcpConnection.java:358) > at org.jgroups.util.Util.close(Util.java:422) > at org.jgroups.blocks.cs.TcpClient.stop(TcpClient.java:85) > at org.jgroups.blocks.cs.BaseServer.close(BaseServer.java:147) > at org.jgroups.util.Util.close(Util.java:422) > at org.jgroups.tests.bla6.lambda$main$0(bla6.java:27) > at org.jgroups.tests.bla6$$Lambda$1/1384010761.run(Unknown Source) > at java.lang.Thread.run(Thread.java:748) > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2350) TCP: connection close can block when send() block on full TCP send-window

by David Stephan (Jira)

[ https://issues.jboss.org/browse/JGRP-2350?page=com.atlassian.jira.plugin.... ] David Stephan reassigned JGRP-2350: ----------------------------------- Assignee: David Stephan (was: Bela Ban) > TCP: connection close can block when send() block on full TCP send-window > ------------------------------------------------------------------------- > > Key: JGRP-2350 > URL: https://issues.jboss.org/browse/JGRP-2350 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: David Stephan > Priority: Major > Fix For: 4.1.1 > > > When a peer is non-responsive (without closing its socket), a TcpConnection.send() can block on a write (state is RUNNABLE!). > The problem is that the TcpConnection cannout be closed either, as TcpConnection.close() tries to acquire the same lock already held by TcpConnection.send(). > See the stack trace below for a sample scenario. > The use case is this one: > * Say we have nodes A (coord), B and C > * There's heavy (clustering) traffic to all 3 nodes, from the 2 clients > * B is isolated by executing 'ifdown bond0' > * At this point, the messages going to B will back up at (say) A because A doesn't get any TCP acks from B > * At some point, depending on the traffic and the size of the sent messages, A will acquire a lock on the send connection to B, to write data, but the write will block as the TCP send-window to B is full (note that the sender thread will still be in state RUNNABLE!) > * After 40s, A suspects B and emits a new view {A,C} > * This causes A's connection to B to be closed and subsequently removed. However, this _won't_ happen, as the connection close will need to acquire the connection lock, which is held by the TCP write > {noformat} > "main" #1 prio=5 os_prio=31 tid=0x00007fbbd3802000 nid=0x2303 runnable [0x0000700009793000] > java.lang.Thread.State: RUNNABLE > at java.net.SocketOutputStream.socketWrite0(Native Method) > at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111) > at java.net.SocketOutputStream.write(SocketOutputStream.java:155) > at java.io.BufferedOutputStream.write(BufferedOutputStream.java:122) > - locked <0x000000079e790a50> (a java.io.BufferedOutputStream) > at java.io.DataOutputStream.write(DataOutputStream.java:107) > - locked <0x000000079e790838> (a java.io.DataOutputStream) > at org.jgroups.blocks.cs.TcpConnection.doSend(TcpConnection.java:161) > at org.jgroups.blocks.cs.TcpConnection.send(TcpConnection.java:131) > at org.jgroups.blocks.cs.TcpClient.send(TcpClient.java:103) > at org.jgroups.tests.bla6.main(bla6.java:35) > "Thread-2" #15 prio=5 os_prio=31 tid=0x00007fbbd2150800 nid=0x6503 waiting on condition [0x000070000bcf6000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x000000079e7871a8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) > at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) > at org.jgroups.blocks.cs.TcpConnection.close(TcpConnection.java:358) > at org.jgroups.util.Util.close(Util.java:422) > at org.jgroups.blocks.cs.TcpClient.stop(TcpClient.java:85) > at org.jgroups.blocks.cs.BaseServer.close(BaseServer.java:147) > at org.jgroups.util.Util.close(Util.java:422) > at org.jgroups.tests.bla6.lambda$main$0(bla6.java:27) > at org.jgroups.tests.bla6$$Lambda$1/1384010761.run(Unknown Source) > at java.lang.Thread.run(Thread.java:748) > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-3625) [DMN Designer] Remove Stunners Explorer widget from the RHS dock

by Roger Martinez (Jira)

[ https://issues.jboss.org/browse/DROOLS-3625?page=com.atlassian.jira.plugi... ] Roger Martinez commented on DROOLS-3625: ---------------------------------------- Yeah [~manstis]! agree. So in general there is nothing customizable on the docks sidefe for each domain, so feel free to implement it as you think it better fits, although I probably prefer the second option as well.. :) > [DMN Designer] Remove Stunners Explorer widget from the RHS dock > ---------------------------------------------------------------- > > Key: DROOLS-3625 > URL: https://issues.jboss.org/browse/DROOLS-3625 > Project: Drools > Issue Type: Task > Components: DMN Editor > Affects Versions: 7.17.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > > The DMN Editor has a "Decision Navigator" widget (in the LHS dock) that currently shows the content of the whole DRG however it will also become the DRD explorer too. This duplicates Stunner's _default_ Explorer widget in the RHS dock. > The DMN Editor should have Stunner's _default_ widget removed. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4124) Decision Service can not be larger than 500 (width) x 200 (height)

by Roger Martinez (Jira)

[ https://issues.jboss.org/browse/DROOLS-4124?page=com.atlassian.jira.plugi... ] Roger Martinez commented on DROOLS-4124: ---------------------------------------- Hey [~manstis] As [~wmedvede] already commented we're not exposing the fields to set the node size in BPMN. For now I think there is no plan to add those form fields in the short term future, anyway as you pointed out, in case those field have to be exposed, we should provide kinda input validation to ensure the values match the size restrictions. This is not implemented yet - well the forms support validations, but the size constrains are specified just in the Shape declaration, so all the information is there and the feature can be implemented, but actually this relationship about the field validations and shape constrains is not provided out of the box. > Decision Service can not be larger than 500 (width) x 200 (height) > ------------------------------------------------------------------ > > Key: DROOLS-4124 > URL: https://issues.jboss.org/browse/DROOLS-4124 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: Screen Shot 2019-06-05 at 9.58.18 AM.png > > > Currently the size widget in the "Properties Panel" is a slider that needs min and max values. We’d need to move to a simple (numeric) Text Box and remove the use of the slider. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1825) [Guided Decision Table] Ability to change HIT policy in a decision table anytime

by Juliano Boesel Mohr (Jira)

[ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugi... ] Juliano Boesel Mohr commented on DROOLS-1825: --------------------------------------------- Thank you, [~jomarko]. I don't have permission to see BAPL Jira's, so thanks for letting me know. > [Guided Decision Table] Ability to change HIT policy in a decision table anytime > -------------------------------------------------------------------------------- > > Key: DROOLS-1825 > URL: https://issues.jboss.org/browse/DROOLS-1825 > Project: Drools > Issue Type: Enhancement > Components: Guided Decision Table Editor > Affects Versions: 7.1.0.Beta2 > Reporter: Ivo Bek > Assignee: Toni Rikkola > Priority: Critical > Labels: UX, UXTeam, drools-tools, verifier > Attachments: DROOLS-1825 (Parent Rule).png, DecisionTable1.png, DecisionTable2.png, GDTAnalysis(a)2x.png, GDTColumns(a)2x.png > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy. > Thus, it should be possible to change HIT policy in a decision table anytime. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-12172) Fix EJB client test permissions when running under the security manager

by James Perkins (Jira)

James Perkins created WFLY-12172: ------------------------------------ Summary: Fix EJB client test permissions when running under the security manager Key: WFLY-12172 URL: https://issues.jboss.org/browse/WFLY-12172 Project: WildFly Issue Type: Bug Components: EJB, Security Manager, Test Suite Reporter: James Perkins Assignee: James Perkins The issue described in WFLY-12171 is being seen more often since the Xnio upgrade (WFCORE-4491). The EJB client tests need the correct permissions to run when the security manager is enabled. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

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 June 2019