February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1439) DMN engine is eagerly evaluating variables in unary test lists

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1439?page=com.atlassian.jira.plugi... ] Edson Tirelli commented on DROOLS-1439: --------------------------------------- Fixed in PR: https://github.com/droolsjbpm/kie-dmn/pull/39 > DMN engine is eagerly evaluating variables in unary test lists > -------------------------------------------------------------- > > Key: DROOLS-1439 > URL: https://issues.jboss.org/browse/DROOLS-1439 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.0.0.Beta6 > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Priority: Critical > Fix For: 7.0.0.Final > > > When entering test in decision table, we usually omit the “=” characters. If there is nothing, it is assumed to be an equal test. When executing with Redhat, this works fine except if I use variable to do the testing. In that case, I need to put the “=” sign for the execution do produce the proper result, otherwise when the value is equals I get null. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1439) DMN engine is eagerly evaluating variables in unary test lists

by Edson Tirelli (JIRA)

Edson Tirelli created DROOLS-1439: ------------------------------------- Summary: DMN engine is eagerly evaluating variables in unary test lists Key: DROOLS-1439 URL: https://issues.jboss.org/browse/DROOLS-1439 Project: Drools Issue Type: Bug Components: dmn engine Affects Versions: 7.0.0.Beta6 Reporter: Edson Tirelli Assignee: Edson Tirelli Priority: Critical Fix For: 7.0.0.Final When entering test in decision table, we usually omit the “=” characters. If there is nothing, it is assumed to be an equal test. When executing with Redhat, this works fine except if I use variable to do the testing. In that case, I need to put the “=” sign for the execution do produce the proper result, otherwise when the value is equals I get null. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8101) Add access constraints to resources referencing Elytron capabilities

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-8101: -------------------------------------- Summary: Add access constraints to resources referencing Elytron capabilities Key: WFLY-8101 URL: https://issues.jboss.org/browse/WFLY-8101 Project: WildFly Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8100) Use RuntimeCapability.setAllowMultipleRegistrations(...) where appropriate

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-8100: ---------------------------------- Summary: Use RuntimeCapability.setAllowMultipleRegistrations(...) where appropriate Key: WFLY-8100 URL: https://issues.jboss.org/browse/WFLY-8100 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-945) User names in Elytron FileSystemRealm are not case sensitive on Windows

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-945?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-945: --------------------------------- On a similar token, it seems like a really good idea to perform Unicode NFKC normalization as well for the same reason. For more info see [the JDK docs for java.text.Normalizer|http://download.java.net/java/jdk9/docs/api/index.ht...]. > User names in Elytron FileSystemRealm are not case sensitive on Windows > ----------------------------------------------------------------------- > > Key: ELY-945 > URL: https://issues.jboss.org/browse/ELY-945 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Blocker > > User names are case sensitive on Linux but not on Windows when using the Elytron {{FileSystemSecurityRealm}} > This is IMO a security issue. And it also affects platform certifications. > If this is by any chance an expected behavior, then it has to be emphasized in documentation and in the domain model too (description of file-system-realm) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-946) Coverity static analysis, suspicious bitwise logical expression, DigestUtil (Elytron)

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-946?page=com.atlassian.jira.plugin.sy... ] Ilia Vassilev moved WFLY-8097 to ELY-946: ----------------------------------------- Project: WildFly Elytron (was: WildFly) Key: ELY-946 (was: WFLY-8097) Component/s: SASL (was: Security) > Coverity static analysis, suspicious bitwise logical expression, DigestUtil (Elytron) > ------------------------------------------------------------------------------------- > > Key: ELY-946 > URL: https://issues.jboss.org/browse/ELY-946 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Critical > > Coverity found suspicious logical operation https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=95638... > See detailed description of possible problem in [1] > If I extend DigestUtilTest#testDecodeByteOrderedInteger with case from [1], test fails > {code} > byte[] inputFF = CodePointIterator.ofString("000000FF").hexDecode().drain(); > assertEquals(0xFF, decodeByteOrderedInteger(inputFF, 0, 4)); > {code} > If I change decodeByteOrderedInteger implementation according to [1], all tests passes. > {code} > result |= (buf[offset + i] & 0xff); > {code} > [1] http://findbugs.sourceforge.net/bugDescriptions.html#BIT_IOR_OF_SIGNED_BYTE > Setting to high priority, because correct behavior of SASL Digest mechanism could be impacted. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-945) User names in Elytron FileSystemRealm are not case sensitive on Windows

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-945?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-945: --------------------------------- Maybe user names in any realm should be case-insensitive (relative to the ROOT locale). Having two users that only differ by case also seems like a potential security issue, and many existing systems (such as email and DNS) that use names as principals in various capacity are also case-insensitive. > User names in Elytron FileSystemRealm are not case sensitive on Windows > ----------------------------------------------------------------------- > > Key: ELY-945 > URL: https://issues.jboss.org/browse/ELY-945 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Blocker > > User names are case sensitive on Linux but not on Windows when using the Elytron {{FileSystemSecurityRealm}} > This is IMO a security issue. And it also affects platform certifications. > If this is by any chance an expected behavior, then it has to be emphasized in documentation and in the domain model too (description of file-system-realm) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8097) Coverity static analysis, suspicious bitwise logical expression, DigestUtil (Elytron)

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFLY-8097?page=com.atlassian.jira.plugin.... ] Ilia Vassilev reassigned WFLY-8097: ----------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > Coverity static analysis, suspicious bitwise logical expression, DigestUtil (Elytron) > ------------------------------------------------------------------------------------- > > Key: WFLY-8097 > URL: https://issues.jboss.org/browse/WFLY-8097 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Critical > > Coverity found suspicious logical operation https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=95638... > See detailed description of possible problem in [1] > If I extend DigestUtilTest#testDecodeByteOrderedInteger with case from [1], test fails > {code} > byte[] inputFF = CodePointIterator.ofString("000000FF").hexDecode().drain(); > assertEquals(0xFF, decodeByteOrderedInteger(inputFF, 0, 4)); > {code} > If I change decodeByteOrderedInteger implementation according to [1], all tests passes. > {code} > result |= (buf[offset + i] & 0xff); > {code} > [1] http://findbugs.sourceforge.net/bugDescriptions.html#BIT_IOR_OF_SIGNED_BYTE > Setting to high priority, because correct behavior of SASL Digest mechanism could be impacted. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8092) Fix Elytron Enabled attributes at ResourceAdapters subsystem

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-8092?page=com.atlassian.jira.plugin.... ] Kabir Khan resolved WFLY-8092. ------------------------------ Fix Version/s: 11.0.0.Alpha1 Resolution: Done > Fix Elytron Enabled attributes at ResourceAdapters subsystem > ------------------------------------------------------------ > > Key: WFLY-8092 > URL: https://issues.jboss.org/browse/WFLY-8092 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Fix For: 11.0.0.Alpha1 > > > This Jira is for all ELYTRON_ENABLED attributes defined in resource adapters subsystem. > The attribute definition has two bugs: > - alternatives defined: > The alternative prevents the user from setting an ELYTRON_ENABLED attribute to false and using one of the alternative attributes, such as SECURITY_DOMAIN because the model will be considered invalid. > The correct is using alternatives at the AUTHENTICATION_CONTEXT attributes instead and doing an extra validation at RaAdd. > - marshalling of the attribute, we need to follow the same standard as other boolean attributes in the module, the attribute must be marshalled as a <elytron-enabled>true</elytron-enabled> instead of <elytron-enabled/>, which is the current form being used now -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5158) WARN ISPN000197: Error updating cluster member list at the boot up

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5158?page=com.atlassian.jira.plugin.... ] Radoslav Husar resolved WFLY-5158. ---------------------------------- Fix Version/s: 11.0.0.Alpha1 Resolution: Done > WARN ISPN000197: Error updating cluster member list at the boot up > ------------------------------------------------------------------ > > Key: WFLY-5158 > URL: https://issues.jboss.org/browse/WFLY-5158 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Beta1, 10.0.0.CR2 > Reporter: Michal Vinkler > Assignee: Radoslav Husar > Priority: Minor > Fix For: 11.0.0.Alpha1 > > > Seen in ejb-ejbservlet and http-session scenarios intermittently (no matter what failover type or cache is used). > When node perf18 is restarted after failover other servers log this error several times: > {code} > [JBossINF] [0m[31m16:11:43,595 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-107) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf18 > [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:752) > [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$6(JGroupsTransport.java:599) > [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$34/238012590.apply(Unknown Source) > [JBossINF] at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > [JBossINF] at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > [JBossINF] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > [JBossINF] at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954) > [JBossINF] at org.infinispan.remoting.transport.jgroups.RspListFuture.timeout(RspListFuture.java:40) > [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$$Lambda$32/2073718099.run(Unknown Source) > [JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266) > [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) > [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > {code} > Server log: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e... > In this particular test run, after perf18 restarted , perf19 logged the first error in 2 seconds, perf20 in 30 seconds, perf21 in 10 seconds. > timeline: > {code} > perf18: [JBossINF] [0m[0m16:11:42,361 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta1) started in 20244ms - Started 747 of 993 services (424 services are lazy, passive or on-demand) > perf19: [JBossINF] [0m[31m16:11:43,595 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-107) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf18 > perf20: [JBossINF] [0m[31m16:12:12,836 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-51) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf18 > perf21: [JBossINF] [0m[31m16:11:52,826 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-22) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf18 > {code} > This error also intermittently appears after server is shutdown. > Total number of errors for this particular test run: 1183 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 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 February 2017