October 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5694) Lack of static type validation when creating a DMN decision table

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5694?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5694: -------------------------------- Description: I mistakenly populated a DMN decision table as in the screenshot attached. However when I saved it I expected some sort of static type analysis and validation that could at least report an error since I populated with strings a column that was been labeled with type number. > Lack of static type validation when creating a DMN decision table > ----------------------------------------------------------------- > > Key: DROOLS-5694 > URL: https://issues.redhat.com/browse/DROOLS-5694 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Mario Fusco > Assignee: Matteo Mortari > Priority: Major > Attachments: screenshot-1.png > > > I mistakenly populated a DMN decision table as in the screenshot attached. However when I saved it I expected some sort of static type analysis and validation that could at least report an error since I populated with strings a column that was been labeled with type number. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5694) Lack of static type validation when creating a DMN decision table

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5694?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5694: -------------------------------- Attachment: screenshot-1.png > Lack of static type validation when creating a DMN decision table > ----------------------------------------------------------------- > > Key: DROOLS-5694 > URL: https://issues.redhat.com/browse/DROOLS-5694 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Mario Fusco > Assignee: Matteo Mortari > Priority: Major > Attachments: screenshot-1.png > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5694) Lack of static type validation when creating a DMN decision table

by Mario Fusco (Jira)

Mario Fusco created DROOLS-5694: ----------------------------------- Summary: Lack of static type validation when creating a DMN decision table Key: DROOLS-5694 URL: https://issues.redhat.com/browse/DROOLS-5694 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Mario Fusco Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5693) SceSim not possible to reorder column despite 4arrows-move mouse cursor

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5693?page=com.atlassian.jira.plug... ] Matteo Mortari reassigned DROOLS-5693: -------------------------------------- Assignee: Yeser Amer (was: Toni Rikkola) > SceSim not possible to reorder column despite 4arrows-move mouse cursor > ----------------------------------------------------------------------- > > Key: DROOLS-5693 > URL: https://issues.redhat.com/browse/DROOLS-5693 > Project: Drools > Issue Type: Bug > Components: Test Scenarios Editor > Reporter: Matteo Mortari > Assignee: Yeser Amer > Priority: Major > Attachments: notpossiblereordercolumn.mp4 > > > As attached video > [^notpossiblereordercolumn.mp4] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13929) Intermittent failures in DeploymentOverlayCLITestCase

by Richard Opalka (Jira)

[ https://issues.redhat.com/browse/WFLY-13929?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFLY-13929: ---------------------------------- Attachment: WatchServiceMindMap.jpg > Intermittent failures in DeploymentOverlayCLITestCase > ----------------------------------------------------- > > Key: WFLY-13929 > URL: https://issues.redhat.com/browse/WFLY-13929 > Project: WildFly > Issue Type: Bug > Components: Management > Reporter: Brian Stansberry > Assignee: Jeff Mesnil > Priority: Major > Attachments: WatchServiceMindMap.jpg > > > Two tests in DeploymentOverlayCLITestCase are failing intermittently but fairly often, e.g. > https://ci.wildfly.org/viewLog.html?buildId=225079&tab=buildResultsDiv&bu... > {code} > java.lang.RuntimeException: java.io.IOException: User limit of inotify instances reached or too many open files > at org.xnio.nio.WatchServiceFileSystemWatcher.<init>(WatchServiceFileSystemWatcher.java:75) > at org.xnio.nio.NioXnio.createFileSystemWatcher(NioXnio.java:241) > at io.undertow.server.handlers.resource.PathResourceManager.registerResourceChangeListener(PathResourceManager.java:256) > at org.wildfly.extension.undertow.deployment.ServletResourceManager.registerResourceChangeListener(ServletResourceManager.java:117) > at io.undertow.server.handlers.resource.CachingResourceManager.registerResourceChangeListener(CachingResourceManager.java:131) > at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:310) > at io.undertow.servlet.core.ManagedServlet.forceInit(ManagedServlet.java:212) > at io.undertow.servlet.handlers.ServletChain.forceInit(ServletChain.java:130) > at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:63) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) > at io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:387) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.io.IOException: User limit of inotify instances reached or too many open files > at sun.nio.fs.LinuxWatchService.<init>(LinuxWatchService.java:64) > at sun.nio.fs.LinuxFileSystem.newWatchService(LinuxFileSystem.java:47) > at org.xnio.nio.WatchServiceFileSystemWatcher.<init>(WatchServiceFileSystemWatcher.java:73) > ... 49 more > </pre></body></html> > at org.jboss.as.test.integration.common.HttpRequest.execute(HttpRequest.java:61) > at org.jboss.as.test.integration.common.HttpRequest.get(HttpRequest.java:82) > at org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase.simpleOverrideInEarAtWarLevelExplodedTest(DeploymentOverlayCLITestCase.java:415) > at org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase.testSimpleOverrideInEarAtWarLevelExploded(DeploymentOverlayCLITestCase.java:383) > {code} > Tests started failing fairly often on September 17. > https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=... > The first failure was against a PR that hasn't been merged yet, so it's likely the problem is in master, not one of the PRs shown on that page. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5693) SceSim not possible to reorder column despite 4arrows-move mouse cursor

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-5693: -------------------------------------- Summary: SceSim not possible to reorder column despite 4arrows-move mouse cursor Key: DROOLS-5693 URL: https://issues.redhat.com/browse/DROOLS-5693 Project: Drools Issue Type: Bug Components: Test Scenarios Editor Reporter: Matteo Mortari Assignee: Toni Rikkola Attachments: notpossiblereordercolumn.mp4 As attached video [^notpossiblereordercolumn.mp4] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13632) If a CMR resource is deployed concurrently then it will overwrite the list of resources that are expected to behave as CMR

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/WFLY-13632?page=com.atlassian.jira.plugi... ] Michael Musgrove reassigned WFLY-13632: --------------------------------------- Assignee: Lin Gao (was: Michael Musgrove) > If a CMR resource is deployed concurrently then it will overwrite the list of resources that are expected to behave as CMR > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13632 > URL: https://issues.redhat.com/browse/WFLY-13632 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Lin Gao > Priority: Blocker > Labels: downstream_dependency > Fix For: 21.0.0.Final > > > Inspecting https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... we can see that it will overwrite the map in https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... because it first get's a copy of a map (https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... -> https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060...) so the maps won't be equal. > This will result in WildFly overwriting the list of resources that Narayana will treat as CMR. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13633) Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/WFLY-13633?page=com.atlassian.jira.plugi... ] Michael Musgrove reassigned WFLY-13633: --------------------------------------- Assignee: Lin Gao (was: Michael Musgrove) > Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR > ------------------------------------------------------------------------------------- > > Key: WFLY-13633 > URL: https://issues.redhat.com/browse/WFLY-13633 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Lin Gao > Priority: Blocker > Labels: downstream_dependency > Fix For: 21.0.0.Final > > > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... does not remove the JNDI name from the list of names that Narayana will treat as CMR resources as it is removed from a copy of the map: https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... > This means that if Narayana encounters another resource at a later time with the same JNDI name it will consider it is a CMR resource. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5692) Inaccurate rule execution in executable model in RHDM 7

by Abhijit Humbe (Jira)

[ https://issues.redhat.com/browse/DROOLS-5692?page=com.atlassian.jira.plug... ] Abhijit Humbe updated DROOLS-5692: ---------------------------------- Attachment: DoubleNaNIssue.java > Inaccurate rule execution in executable model in RHDM 7 > -------------------------------------------------------- > > Key: DROOLS-5692 > URL: https://issues.redhat.com/browse/DROOLS-5692 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.44.0.Final > Reporter: Abhijit Humbe > Assignee: Mario Fusco > Priority: Major > Attachments: DoubleNaNIssue.java > > > Model compile generate code that inaccurately fires the rule in comparison to non executable model code created rulebase or in 6.x. > {code:java} > rule "test_rule" > dialect "java" > when > $nanTest : DoubleNaNTest( $testDouble1 : testDouble1 , $testDouble2 : testDouble2 , $testDouble1 + 10 > $testDouble2 , testBoolean!=null, testBoolean==false) > then > System.out.println("rule_a fired "); > $nanTest.setTestBoolean(true); > update($nanTest); > end > DoubleNaNTest nan = new DoubleNaNTest(); > nan.setTestBoolean(false); > nan.setTestDouble1(Double.NaN);//Double.NaN > nan.setTestDouble2(100.0); > KieSession ksession = sumKieBaseShort.newKieSession(); > ksession.insert(nan); > {code} > > Expected: > Above rule should not fired in executable model. > Actual result: > Above rule fired in executable model. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13933) access-log entries might become lost during the shutdown even if graceful timeout is specified

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-13933?page=com.atlassian.jira.plugi... ] Bartosz Baranowski commented on WFLY-13933: ------------------------------------------- [~flavia.rainone], [~ropalka] ^^ > access-log entries might become lost during the shutdown even if graceful timeout is specified > ------------------------------------------------------------------------------------------------ > > Key: WFLY-13933 > URL: https://issues.redhat.com/browse/WFLY-13933 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 20.0.0.Final > Reporter: Masafumi Miura > Assignee: Bartosz Baranowski > Priority: Major > > access-log has a possibility to be lost during WildFly shutdown even if a graceful timeout is specified. > If I understand correctly, access-log processing runs on a different thread from the application processing and the graceful shutdown does not care about it. > Since WildFly 16+, WFCORE-1632 changed the shutdown behavior to wait only for 100ms (hard-coded). So, WildFly 16+ does not wait for completing a task worker thread processing access-log. > I understand the purpose of WFCORE-1632. However, it might be good if we have an option to tune the wait time. (Of course, it would be difficult to know how long wait time is sufficient for completion. And specifying a large wait time can be a cause of long shutdown time. So, it's still questionable how it's useful.) > Or, if it's possible to implement that the graceful shutdown can wait for access-log processing, it would be better. (This might be RFE?). -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 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 October 2020