May 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4047) Unable to use CSV in a ruleTemplate

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-4047?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-4047: ------------------------------------- Hi [~abaxter] I'll give a look asap. > Unable to use CSV in a ruleTemplate > ----------------------------------- > > Key: DROOLS-4047 > URL: https://issues.jboss.org/browse/DROOLS-4047 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 6.5.0.Final, 7.21.0.Final > Environment: Any Java env > Reporter: Adam Baxter > Assignee: Mario Fusco > Priority: Major > Attachments: csv_import_test.tar.gz > > > I believe there is a bug where you cannot use a CSV file to use as a decision table to drive a ruleTemplate. Our issue appears to be a duplicate of the one mentioned in this pull request -https://github.com/kiegroup/drools/pull/1920 > The drools version we're using is 6.50.FINAL, but the reproducer I've attached is for the latest released version. > We'd like to move away from binary files as they're opaque to most version control and it makes branching difficult. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12098) Thread context class loader is wrong for ScheduledExecutorService threads

by Paul Pogonyshev (Jira)

[ https://issues.jboss.org/browse/WFLY-12098?page=com.atlassian.jira.plugin... ] Paul Pogonyshev commented on WFLY-12098: ---------------------------------------- When trying to write a workaround, I determined that the problem is that executor services change as an application is being deployed from "broken" (with class loaders that cannot find the application's classes) to correct ones. So, the first calls to executor services were broken, not the subsequent. What changed between 14 and 16 is probably order of some steps in deployment procedure that made our application use ScheduledExecutorService "earlier". Is there a good way for the application to determine when exactly JNDI lookups return "proper" objects that are correctly initialized for the application's deployment? > Thread context class loader is wrong for ScheduledExecutorService threads > ------------------------------------------------------------------------- > > Key: WFLY-12098 > URL: https://issues.jboss.org/browse/WFLY-12098 > Project: WildFly > Issue Type: Bug > Components: Class Loading > Affects Versions: 16.0.0.Final > Reporter: Paul Pogonyshev > Assignee: Richard Opalka > Priority: Major > > Tasks submitted to the standard ScheduledExecutorService (JNDI: java:comp/DefaultManagedScheduledExecutorService) are executed in threads with class loader that cannot find application classes. This is a regression in 16.0 compared to 14.0 (haven't tested 15). Tasks submitted to the simple ExecutorService (JNDI: java:comp/DefaultManagedExecutorService) see the correct class loader. > I.e. if I submit something like > () -> { System.out.println (Thread.currentThread ().getContextClassLoader (); } > to both services (i.e. exactly the same task), I get the following output. For ScheduledExecutorService (wrong): > ModuleClassLoader for Module "org.jboss.as.ee" version 16.0.0.Final from local module loader @275710fc (finder: local module finder @525f1e4e (roots: [...]/wildfly/modules,[...]/wildfly/modules/system/layers/base)) > For ExecutorService (as expected): > ModuleClassLoader for Module "deployment.[...].war" from Service Module Loader > Plain ExecutorService sees exactly the same class loader as normal threads in which HTTP request are processed. In version 14.0 this was also true for ScheduledExecutorService. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-164) After unsuccessful connect attempts (Client Side) the Endpoint is not closed

by Leticia Konno (Jira)

Leticia Konno created REMJMX-164: ------------------------------------ Summary: After unsuccessful connect attempts (Client Side) the Endpoint is not closed Key: REMJMX-164 URL: https://issues.jboss.org/browse/REMJMX-164 Project: Remoting JMX Issue Type: Bug Components: Connection Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.3.CR1, 3.1.0.Beta1 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4056) DMN Editor: Keyboard shortcut functionality on mouse initiated focus.

by Elizabeth Clayton (Jira)

Elizabeth Clayton created DROOLS-4056: ----------------------------------------- Summary: DMN Editor: Keyboard shortcut functionality on mouse initiated focus. Key: DROOLS-4056 URL: https://issues.jboss.org/browse/DROOLS-4056 Project: Drools Issue Type: Bug Components: DMN Editor Reporter: Elizabeth Clayton Assignee: Guilherme Gomes Keyboard shortcut works only when arrow keys are used to focus on the DMN type element. If the user start editing a field with mouse and type "CTRL-S" to save it, the shortcut does not work. Note: Team invested CTRL-S, but there was some potential conflict with built in browser controls. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11218) IIOP call does not work with transaction started on client side when run on IBM JDK

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11218?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11218: --------------------------------- Labels: blocker-WF17 blocker-WF18 (was: blocker-WF17) > IIOP call does not work with transaction started on client side when run on IBM JDK > ----------------------------------------------------------------------------------- > > Key: WFLY-11218 > URL: https://issues.jboss.org/browse/WFLY-11218 > Project: WildFly > Issue Type: Bug > Components: IIOP > Affects Versions: 14.0.0.Final, 15.0.0.Beta1 > Environment: IBM JDK 8 > Reporter: Ivan Straka > Assignee: Tomasz Adamski > Priority: Blocker > Labels: blocker-WF17, blocker-WF18 > > Issue is valid only for IBM JDK 8...scenario works on oracle jdk 8 and 11 and openjdk 8. > Scenario (using CORBA): > # start transaction > # lookup > # IIOP call > # EJB perform a basic operation and return (no failure is expected) > IIOP call fails with following exception: > {code:java} > java.lang.NullPointerException: null > at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sentFullMessage(CorbaMessageMediatorImpl.java:429) > at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sendCancelRequestIfFinalFragmentNotSent(CorbaMessageMediatorImpl.java:394) > at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.endRequest(CorbaClientRequestDispatcherImpl.java:895) > at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.releaseReply(CorbaClientDelegateImpl.java:167) > at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:253) > at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:139) > at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:91) > at com.sun.jndi.cosnaming.CNCtx.setOrbAndRootContext(CNCtx.java:408) > at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:274) > at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:132) > at com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:61) > at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:695) > at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:324) > at javax.naming.InitialContext.init(InitialContext.java:255) > at javax.naming.InitialContext.<init>(InitialContext.java:227) > at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:93) > at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:103) > at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.lookupCrashBeanOverIIOP(JMSCrashRecoveryTestCase.java:164) > at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.callCrashTest(JMSCrashRecoveryTestCase.java:126) > {code} > When transaction is not started on client side, IIOP call works smoothly. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3972) Evaluation of facts hasn't been affected by 'modify()' when parsing String to Double

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3972?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-3972. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/aa986a57724e2f16cabea9c084b8e16... > Evaluation of facts hasn't been affected by 'modify()' when parsing String to Double > ------------------------------------------------------------------------------------- > > Key: DROOLS-3972 > URL: https://issues.jboss.org/browse/DROOLS-3972 > Project: Drools > Issue Type: Bug > Components: executable model > Affects Versions: 7.20.0.Final > Environment: Ubuntu > Reporter: Almas Toimbekov > Assignee: Mario Fusco > Priority: Major > Labels: double, evaluation, execution, parse > > When I modify amount in an example below from 5 to 20 (both are Strings) and then try to evaluate this fact parsing it to Double - the third rule doesn't fire. But it fires when use 'update()' instead of 'modify() {}' -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4050) Error is thrown when DMN expected date value differs from the actual value

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-4050?page=com.atlassian.jira.plugi... ] Jozef Marko closed DROOLS-4050. ------------------------------- Resolution: Out of Date > Error is thrown when DMN expected date value differs from the actual value > -------------------------------------------------------------------------- > > Key: DROOLS-4050 > URL: https://issues.jboss.org/browse/DROOLS-4050 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.22.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Major > Labels: ScenarioSimulation > Attachments: Screenshot from 2019-05-20 11-48-39.png, error.log, outage.zip > > > If the test scenario computes with date fields, there is an exceptio0n if the expected value differs from the actual. If the expected value is same as actual, scenario works fine. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4050) Error is thrown when DMN expected date value differs from the actual value

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-4050?page=com.atlassian.jira.plugi... ] Jozef Marko reopened DROOLS-4050: --------------------------------- > Error is thrown when DMN expected date value differs from the actual value > -------------------------------------------------------------------------- > > Key: DROOLS-4050 > URL: https://issues.jboss.org/browse/DROOLS-4050 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.22.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Major > Labels: ScenarioSimulation > Attachments: Screenshot from 2019-05-20 11-48-39.png, error.log, outage.zip > > > If the test scenario computes with date fields, there is an exceptio0n if the expected value differs from the actual. If the expected value is same as actual, scenario works fine. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4050) Error is thrown when DMN expected date value differs from the actual value

by Daniele Zonca (Jira)

[ https://issues.jboss.org/browse/DROOLS-4050?page=com.atlassian.jira.plugi... ] Daniele Zonca closed DROOLS-4050. --------------------------------- Resolution: Done Fixed by https://issues.jboss.org/browse/DROOLS-4028 > Error is thrown when DMN expected date value differs from the actual value > -------------------------------------------------------------------------- > > Key: DROOLS-4050 > URL: https://issues.jboss.org/browse/DROOLS-4050 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.22.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Major > Labels: ScenarioSimulation > Attachments: Screenshot from 2019-05-20 11-48-39.png, error.log, outage.zip > > > If the test scenario computes with date fields, there is an exceptio0n if the expected value differs from the actual. If the expected value is same as actual, scenario works fine. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-163) After unsuccessful connect attempts (Client Side) the Endpoint is not closed

by Darran Lofthouse (Jira)

Darran Lofthouse created REMJMX-163: --------------------------------------- Summary: After unsuccessful connect attempts (Client Side) the Endpoint is not closed Key: REMJMX-163 URL: https://issues.jboss.org/browse/REMJMX-163 Project: Remoting JMX Issue Type: Bug Components: Connection Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.3.CR1, 3.1.0.Beta1 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

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