October 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13935) dir-contexts referral-mode attribute upper/lower case discrepancy

by Jan Stourac (Jira)

Jan Stourac created WFLY-13935: ---------------------------------- Summary: dir-contexts referral-mode attribute upper/lower case discrepancy Key: WFLY-13935 URL: https://issues.redhat.com/browse/WFLY-13935 Project: WildFly Issue Type: Bug Components: CLI Affects Versions: 20.0.0.Final, 19.0.0.Final, 18.0.0.Final, 17.0.0.Final, 16.0.0.Final, 15.0.0.Final Reporter: Jan Stourac Assignee: Jean Francois Denise Attachments: reproducer.sh There seems to be a discrepancy of the '/elytron/dir-context[referral-mode]' attribute represented value. When there is no value set (default is applied), then particular value is printed in upper-case - {{IGNORE}}. Although, when we set custom value, then when we try to read it, it is printed in lower-case now, e.g. {{ignore}} (lower-case is also saved in raw xml configuration). This behavior started with {{WildFly 15.0.0.Final}} and is still present in {{WildFly 20.0.0.Final}}. Not sure whether this change was intentional. I was able to find only this issue which may be kind of related WFCORE-3971. In {{WildFly 14.0.0.Final}} there was always upper-case value printed. What is the issue here: # If this change was NOT intentional -> consider whether we would like to go to original behavior (upper-case returned always, including raw xml) # If this change was intentional -> we should probably update so that even default value is lower-case as otherwise this behavior can be confusing for the customer - sometimes there is printed value in upper-case only, otherwise lower-case only. Also, this may be complication for customer automation scripts too. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5695) Lack of runtime type validation when running the simulation for a badly written DMN decision table

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5695?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5695: -------------------------------- Description: I mistakenly populated a DMN decision table as in the screenshot attached. However when I try to evaluate the table with scenario simulaton I expected some sort of type analysis that could at least report an error since I populated with strings a column that was been labeled with type number. (was: 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 runtime type validation when running the simulation for a badly written DMN decision table > -------------------------------------------------------------------------------------------------- > > Key: DROOLS-5695 > URL: https://issues.redhat.com/browse/DROOLS-5695 > 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 try to evaluate the table with scenario simulaton I expected some sort of type analysis 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, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5695) Lack of runtime type validation when running the simulation for a badly written DMN decision table

by Mario Fusco (Jira)

Mario Fusco created DROOLS-5695: ----------------------------------- Summary: Lack of runtime type validation when running the simulation for a badly written DMN decision table Key: DROOLS-5695 URL: https://issues.redhat.com/browse/DROOLS-5695 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Mario Fusco Assignee: Matteo Mortari 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, 3 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: -------------------------------- 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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