March 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13060) EJB client behaviour is different when deployed in a .war compared to a .ear and can result in a OOME

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFLY-13060?page=com.atlassian.jira.plugi... ] Richard Achmatowicz commented on WFLY-13060: -------------------------------------------- I'm getting a report from Google that the download link is 4.3 Gb: {quote} Google Drive can't scan this file for viruses. 02567454.zip (4.3G) is too large for Google to scan for viruses. Would you still like to download this file? {quote} Am I trying to download the wrong file? Why 4.3Gb for a reproducer? > EJB client behaviour is different when deployed in a .war compared to a .ear and can result in a OOME > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-13060 > URL: https://issues.redhat.com/browse/WFLY-13060 > Project: WildFly > Issue Type: Feature Request > Components: EJB, Remoting > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Critical > > EAP 7 - EJB client behaviour is different when deployed in a .war compared to a .ear > .war gives poor performance and runs out of native memory > .ear works ok -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1095) QE Guide for OSSM Kiali release testing

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1095: ------------------------------------- Summary: QE Guide for OSSM Kiali release testing Key: SWSQE-1095 URL: https://issues.redhat.com/browse/SWSQE-1095 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1941) Update the Travis settings to use OpenJDK 8

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1941: ------------------------------------- Summary: Update the Travis settings to use OpenJDK 8 Key: ELY-1941 URL: https://issues.redhat.com/browse/ELY-1941 Project: WildFly Elytron Issue Type: Bug Components: Build Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.6.6.CR1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1940) Elytron LDAP Squashes Authentication Exception

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1940?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1940: ---------------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/1376 (was: https://github.com/wildfly-security/wildfly-elytron/pull/1378, https://github.com/wildfly-security/wildfly-elytron/pull/1377, https://github.com/wildfly-security/wildfly-elytron/pull/1376) > Elytron LDAP Squashes Authentication Exception > ---------------------------------------------- > > Key: ELY-1940 > URL: https://issues.redhat.com/browse/ELY-1940 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Lin Gao > Assignee: Lin Gao > Priority: Major > Labels: downstream_dependency, elytron, ldap, logging > Fix For: 1.6.6.CR1 > > > Trace logging shows: > {code} > 2020-03-10 13:51:38,549 DEBUG [org.wildfly.security] (management task-1) Found entry [uid=dguthrie,ou=users,dc=example,dc=com]. > 2020-03-10 13:51:38,550 DEBUG [org.wildfly.security] (management task-1) Identity for principal [dguthrie] found at [uid=dguthrie,ou=users,dc=example,dc=com]. > 2020-03-10 13:51:38,581 DEBUG [org.wildfly.security] (management task-1) Credential direct evidence verification failed. DN: [uid=dguthrie,ou=users,dc=example,dc=com] > 2020-03-10 13:51:38,581 DEBUG [org.wildfly.security] (management task-1) Context [javax.naming.ldap.InitialLdapContext@25061db2] was closed. Connection closed or just returned to the pool. > 2020-03-10 13:51:38,581 TRACE [org.wildfly.security] (management task-1) Handling AuthenticationCompleteCallback: fail > 2020-03-10 13:51:38,582 TRACE [org.jboss.remoting.remote.server] (management task-1) Server sending authentication rejected: javax.security.sasl.SaslException: ELY05013: Authentication mechanism password not verified > {code} > > Where "Credential direct evidence verification failed. DN [uid=dguthrie,ou=users,dc=example,dc=com]" is missing the exception or even a reason. > In DirectEvidenceVerifier.java around line 102 in the Exception handler it has > {code} > log.debugf("Credential direct evidence verification failed. DN: [%s]", distinguishedName,e); > {code} > In this case, the "e" is the exception, but that parameter position is for the string formatting for which there is no token in the formatter. I believe what they meant to write was: > {code} > log.debugf(e, "Credential direct evidence verification failed. DN: [%s]", distinguishedName); > {code} > See [GitHub|https://github.com/jbossas/wildfly-elytron/blob/96c2273dc0503a23d1...] > where the first parameter is the exception. A customer is migrating from legacy to elytron, and they have been using the LDAP error codes in the log for their internal IT to help figure out why people failed login. It's also invaluable for support. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1940) Elytron LDAP Squashes Authentication Exception

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1940?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1940: ---------------------------------- Fix Version/s: 1.6.6.CR1 > Elytron LDAP Squashes Authentication Exception > ---------------------------------------------- > > Key: ELY-1940 > URL: https://issues.redhat.com/browse/ELY-1940 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Lin Gao > Assignee: Lin Gao > Priority: Major > Labels: downstream_dependency, elytron, ldap, logging > Fix For: 1.6.6.CR1 > > > Trace logging shows: > {code} > 2020-03-10 13:51:38,549 DEBUG [org.wildfly.security] (management task-1) Found entry [uid=dguthrie,ou=users,dc=example,dc=com]. > 2020-03-10 13:51:38,550 DEBUG [org.wildfly.security] (management task-1) Identity for principal [dguthrie] found at [uid=dguthrie,ou=users,dc=example,dc=com]. > 2020-03-10 13:51:38,581 DEBUG [org.wildfly.security] (management task-1) Credential direct evidence verification failed. DN: [uid=dguthrie,ou=users,dc=example,dc=com] > 2020-03-10 13:51:38,581 DEBUG [org.wildfly.security] (management task-1) Context [javax.naming.ldap.InitialLdapContext@25061db2] was closed. Connection closed or just returned to the pool. > 2020-03-10 13:51:38,581 TRACE [org.wildfly.security] (management task-1) Handling AuthenticationCompleteCallback: fail > 2020-03-10 13:51:38,582 TRACE [org.jboss.remoting.remote.server] (management task-1) Server sending authentication rejected: javax.security.sasl.SaslException: ELY05013: Authentication mechanism password not verified > {code} > > Where "Credential direct evidence verification failed. DN [uid=dguthrie,ou=users,dc=example,dc=com]" is missing the exception or even a reason. > In DirectEvidenceVerifier.java around line 102 in the Exception handler it has > {code} > log.debugf("Credential direct evidence verification failed. DN: [%s]", distinguishedName,e); > {code} > In this case, the "e" is the exception, but that parameter position is for the string formatting for which there is no token in the formatter. I believe what they meant to write was: > {code} > log.debugf(e, "Credential direct evidence verification failed. DN: [%s]", distinguishedName); > {code} > See [GitHub|https://github.com/jbossas/wildfly-elytron/blob/96c2273dc0503a23d1...] > where the first parameter is the exception. A customer is migrating from legacy to elytron, and they have been using the LDAP error codes in the log for their internal IT to help figure out why people failed login. It's also invaluable for support. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5103) Implement PMML model archetype

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5103?page=com.atlassian.jira.plug... ] Gabriele Cardosi closed DROOLS-5103. ------------------------------------ Resolution: Done > Implement PMML model archetype > ------------------------------ > > Key: DROOLS-5103 > URL: https://issues.redhat.com/browse/DROOLS-5103 > Project: Drools > Issue Type: Task > Components: PMML > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: PMMLRefactor, TrustyAI > > Create a maven archetype to auomatically generate stub modele-specific module inside new pmml implementation -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5119) [Guided Rule Editor] Workbench BigDecimal value turns into 0.0 in DRL

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-5119?page=com.atlassian.jira.plug... ] Michael Anstis resolved DROOLS-5119. ------------------------------------ Fix Version/s: 7.34.0.Final Resolution: Out of Date [~bhala.hadkar] confirmed this works OK in {{7.34.0-Final}}. Yay. > [Guided Rule Editor] Workbench BigDecimal value turns into 0.0 in DRL > --------------------------------------------------------------------- > > Key: DROOLS-5119 > URL: https://issues.redhat.com/browse/DROOLS-5119 > Project: Drools > Issue Type: Bug > Components: Examples (Workbench), Guided Rule Editor > Reporter: Bhala Hadkar > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Fix For: 7.34.0.Final > > Attachments: DROOLS-5119-rule.png, Workbench-Guided-Rule.png, drools.png > > > When I set up a Guided rule on Workbench having a comparison condition on one of the domain field of type Big Decimal then the int value entered through literal text disappears and turns into 0.0B. > For e.g. if you look at this Guided Rule screenshot the literal value 100 turned into 0.0. > !Workbench-Guided-Rule.png|thumbnail! > Also in the drools the value becomes 0.0B. > !drools.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5119) [Guided Rule Editor] Workbench BigDecimal value turns into 0.0 in DRL

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-5119?page=com.atlassian.jira.plug... ] Michael Anstis edited comment on DROOLS-5119 at 3/16/20 11:08 AM: ------------------------------------------------------------------ [~bhala.hadkar] confirmed this works OK in {{7.34.0.Final}}. Yay. was (Author: manstis): [~bhala.hadkar] confirmed this works OK in {{7.34.0-Final}}. Yay. > [Guided Rule Editor] Workbench BigDecimal value turns into 0.0 in DRL > --------------------------------------------------------------------- > > Key: DROOLS-5119 > URL: https://issues.redhat.com/browse/DROOLS-5119 > Project: Drools > Issue Type: Bug > Components: Examples (Workbench), Guided Rule Editor > Reporter: Bhala Hadkar > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Fix For: 7.34.0.Final > > Attachments: DROOLS-5119-rule.png, Workbench-Guided-Rule.png, drools.png > > > When I set up a Guided rule on Workbench having a comparison condition on one of the domain field of type Big Decimal then the int value entered through literal text disappears and turns into 0.0B. > For e.g. if you look at this Guided Rule screenshot the literal value 100 turned into 0.0. > !Workbench-Guided-Rule.png|thumbnail! > Also in the drools the value becomes 0.0B. > !drools.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-266) log4j2-jboss-logmanager LevelTranslator NullPointer

by James Perkins (Jira)

[ https://issues.redhat.com/browse/LOGMGR-266?page=com.atlassian.jira.plugi... ] James Perkins commented on LOGMGR-266: -------------------------------------- Good catch. I wasn't aware the level could be {{null}}. I've created https://github.com/jboss-logging/log4j2-jboss-logmanager/issues/3 for this as well. I'll leave this open for now as a reminder. > log4j2-jboss-logmanager LevelTranslator NullPointer > --------------------------------------------------- > > Key: LOGMGR-266 > URL: https://issues.redhat.com/browse/LOGMGR-266 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: Boris Unckel > Priority: Critical > > We found the following Nullpointer Exception > {code} > Caused by: java.lang.NullPointerException > at org.jboss.logmanager.log4j.LevelTranslator.translateLevel(LevelTranslator.java:95) > at org.jboss.logmanager.log4j.JBossLogger.getLevel(JBossLogger.java:156) > {code} > .... > Reason seems that LevelTranslator is not defensive enough. Suggestion: > {code} > java.util.logging.Level translateLevel(final Level level) { > //level null is same as level not translated > if(level == null) { > return org.jboss.logmanager.Level.INFO; > } > final java.util.logging.Level result = log4jToJul.get(level.intLevel()); > return result == null ? org.jboss.logmanager.Level.INFO : result; > } > Level translateLevel(final java.util.logging.Level level) { > //level null is same as level not translated > if(level == null) { > return Level.INFO; > } > final Level result = julToLog4j.get(level.intValue()); > return result == null ? Level.INFO : result; > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3339) Refactor the PMML Regression

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-3339?page=com.atlassian.jira.plug... ] Gabriele Cardosi closed DROOLS-3339. ------------------------------------ Resolution: Done > Refactor the PMML Regression > ---------------------------- > > Key: DROOLS-3339 > URL: https://issues.redhat.com/browse/DROOLS-3339 > Project: Drools > Issue Type: Task > Components: PMML > Affects Versions: 7.14.0.Final > Reporter: Michael McCune > Assignee: Gabriele Cardosi > Priority: Critical > Labels: PMMLRefactor, TrustyAI > > Replace the current DRL generation for regression calculation by a specialized regression library, in order to simplify the code and improve compilation and runtime performance. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 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 March 2020