June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1259) Not logged exceptions in ElytronAuthenticator

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-1259?page=com.atlassian.jira.plugin.s... ] Ondrej Lukas updated ELY-1259: ------------------------------ Affects Version/s: 1.1.0.Beta52 > Not logged exceptions in ElytronAuthenticator > --------------------------------------------- > > Key: ELY-1259 > URL: https://issues.jboss.org/browse/ELY-1259 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta52 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > {{org.wildfly.security.auth.util.ElytronAuthenticator}} includes some try-catch blocks where some Exception is caught, but it is thrown away, e.g. [1]. It should be rather logged at trace level. > e.g. this issue causes that Exception mentioned in JBEAP-11725 is hidden. However showing this Exception in server log would be helpful for users. > [1] https://github.com/wildfly-security/wildfly-elytron/blob/4df6f4726b7cf070... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1259) Not logged exceptions in ElytronAuthenticator

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-1259: --------------------------------- Summary: Not logged exceptions in ElytronAuthenticator Key: ELY-1259 URL: https://issues.jboss.org/browse/ELY-1259 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse {{org.wildfly.security.auth.util.ElytronAuthenticator}} includes some try-catch blocks where some Exception is caught, but it is thrown away, e.g. [1]. It should be rather logged at trace level. e.g. this issue causes that Exception mentioned in JBEAP-11725 is hidden. However showing this Exception in server log would be helpful for users. [1] https://github.com/wildfly-security/wildfly-elytron/blob/4df6f4726b7cf070... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2196) TP: internal thread pool is not shut down

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2196?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2196: --------------------------- Description: In {{TP.destroy()}}, the regular thread pool and timer are shut down, but not the internal thread pool. The result is that sometimes closing a channel takes a longer time (the max idle time for a thread in the pool). This only happens when an internal thread is active at the time of shut down. Also use a separate thread factory for internal threads, so we can see by the naming whether a thread is regular or internal, e.g. "jgroups-23" (regular) versus "jgroups-int-33" was: In {{TP.destroy()}}, the regular thread pool and timer are shut down, but not the intrnal thread pool. Also use a separate thread factory for internal threads, so we can see by the naming whether a thread is regular or internal, e.g. "jgroups-23" (regular) versus "jgroups-int-33" > TP: internal thread pool is not shut down > ----------------------------------------- > > Key: JGRP-2196 > URL: https://issues.jboss.org/browse/JGRP-2196 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.4 > > > In {{TP.destroy()}}, the regular thread pool and timer are shut down, but not the internal thread pool. The result is that sometimes closing a channel takes a longer time (the max idle time for a thread in the pool). This only happens when an internal thread is active at the time of shut down. > Also use a separate thread factory for internal threads, so we can see by the naming whether a thread is regular or internal, e.g. "jgroups-23" (regular) versus "jgroups-int-33" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1258) ElytronAuthenticator.getPasswordAuthentication() cannot obtain PasswordFactory for Elytron algorithms

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-1258: --------------------------------- Summary: ElytronAuthenticator.getPasswordAuthentication() cannot obtain PasswordFactory for Elytron algorithms Key: ELY-1258 URL: https://issues.jboss.org/browse/ELY-1258 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Blocker {{ElytronAuthenticator.getPasswordAuthentication()}} cannot obtain PasswordFactory for Elytron related algorithms. It is caused by missing WildFlyElytronProvider (since {{Security::getProviders}} is used for obtaining providers) for {{PasswordFactory.getInstance}} in [1]. It results to hidden NoSuchAlgorithmException with message _ELY08028: Invalid algorithm "clear"_ and stacktrace: {code} org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:121) org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:75) org.wildfly.security.auth.util.ElytronAuthenticator.getPasswordAuthentication(ElytronAuthenticator.java:92) java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317) ... {code} It causes that even if element {{net-authenticator}} from Elytron client configuration file correctly sets ElytronAuthenticator as default Authenticator, it is not able to work with Elytron related algorithms which means it breaks feature from RFE7-567 - Client Side Security (Elytron Client) => we request blocker flag. [1] https://github.com/wildfly-security/wildfly-elytron/blob/4df6f4726b7cf070... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1258) ElytronAuthenticator.getPasswordAuthentication() cannot obtain PasswordFactory for Elytron algorithms

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-1258?page=com.atlassian.jira.plugin.s... ] Ondrej Lukas updated ELY-1258: ------------------------------ Affects Version/s: 1.1.0.Beta52 > ElytronAuthenticator.getPasswordAuthentication() cannot obtain PasswordFactory for Elytron algorithms > ----------------------------------------------------------------------------------------------------- > > Key: ELY-1258 > URL: https://issues.jboss.org/browse/ELY-1258 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta52 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Blocker > > {{ElytronAuthenticator.getPasswordAuthentication()}} cannot obtain PasswordFactory for Elytron related algorithms. It is caused by missing WildFlyElytronProvider (since {{Security::getProviders}} is used for obtaining providers) for {{PasswordFactory.getInstance}} in [1]. > It results to hidden NoSuchAlgorithmException with message _ELY08028: Invalid algorithm "clear"_ and stacktrace: > {code} > org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:121) > org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:75) > org.wildfly.security.auth.util.ElytronAuthenticator.getPasswordAuthentication(ElytronAuthenticator.java:92) > java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317) > ... > {code} > It causes that even if element {{net-authenticator}} from Elytron client configuration file correctly sets ElytronAuthenticator as default Authenticator, it is not able to work with Elytron related algorithms which means it breaks feature from RFE7-567 - Client Side Security (Elytron Client) => we request blocker flag. > [1] https://github.com/wildfly-security/wildfly-elytron/blob/4df6f4726b7cf070... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2196) TP: internal thread pool is not shut down

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2196?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2196: --------------------------- Description: In {{TP.destroy()}}, the regular thread pool and timer are shut down, but not the intrnal thread pool. Also use a separate thread factory for internal threads, so we can see by the naming whether a thread is regular or internal, e.g. "jgroups-23" (regular) versus "jgroups-int-33" was:In {{TP.destroy()}}, the regular thread pool and timer are shut down, but not the intrnal thread pool. > TP: internal thread pool is not shut down > ----------------------------------------- > > Key: JGRP-2196 > URL: https://issues.jboss.org/browse/JGRP-2196 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.4 > > > In {{TP.destroy()}}, the regular thread pool and timer are shut down, but not the intrnal thread pool. > Also use a separate thread factory for internal threads, so we can see by the naming whether a thread is regular or internal, e.g. "jgroups-23" (regular) versus "jgroups-int-33" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2196) TP: internal thread pool is not shut down

by Bela Ban (JIRA)

Bela Ban created JGRP-2196: ------------------------------ Summary: TP: internal thread pool is not shut down Key: JGRP-2196 URL: https://issues.jboss.org/browse/JGRP-2196 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0.4 In {{TP.destroy()}}, the regular thread pool and timer are shut down, but not the intrnal thread pool. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1623) Inappropriate "Missing Header" DecisionTableParseException

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1623?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1623: -------------------------------- Component/s: core engine > Inappropriate "Missing Header" DecisionTableParseException > ---------------------------------------------------------- > > Key: DROOLS-1623 > URL: https://issues.jboss.org/browse/DROOLS-1623 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Christian Lowe > Assignee: Mario Fusco > > Introduced in [this commit|https://github.com/kiegroup/drools/commit/0bd98541b3177bdc7d0e1f5f...], > A condition in the "when" section of a drt file, which begins with the word package, such as: > {code:mvel} > $box: Box ( > packageName == $productPackageName, > ) > {code} > ... will cause an error: > {code:java} > org.drools.template.parser.DecisionTableParseException: Missing header > at org.drools.template.parser.DefaultTemplateContainer.parseTemplate(DefaultTemplateContainer.java:127) > ....... > {code} > Previously, the parsing logic would only look for unindented keywords. Now, DefaultTemplateContainer will trim the line, see that it starts with the word "package," and error out. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1623) Inappropriate "Missing Header" DecisionTableParseException

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1623?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1623: -------------------------------- Sprint: 2017 Week 24-25 > Inappropriate "Missing Header" DecisionTableParseException > ---------------------------------------------------------- > > Key: DROOLS-1623 > URL: https://issues.jboss.org/browse/DROOLS-1623 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Christian Lowe > Assignee: Mario Fusco > > Introduced in [this commit|https://github.com/kiegroup/drools/commit/0bd98541b3177bdc7d0e1f5f...], > A condition in the "when" section of a drt file, which begins with the word package, such as: > {code:mvel} > $box: Box ( > packageName == $productPackageName, > ) > {code} > ... will cause an error: > {code:java} > org.drools.template.parser.DecisionTableParseException: Missing header > at org.drools.template.parser.DefaultTemplateContainer.parseTemplate(DefaultTemplateContainer.java:127) > ....... > {code} > Previously, the parsing logic would only look for unindented keywords. Now, DefaultTemplateContainer will trim the line, see that it starts with the word "package," and error out. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1624) Map Handling with Property Reactive Always Enabled

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1624?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1624: -------------------------------- Sprint: 2017 Week 24-25 > Map Handling with Property Reactive Always Enabled > -------------------------------------------------- > > Key: DROOLS-1624 > URL: https://issues.jboss.org/browse/DROOLS-1624 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.0.0.Final > Environment: * JDK8 > * Docker running Alpine > Reporter: KimJohn Quinn > Assignee: Mario Fusco > Priority: Minor > > Referencing a conversation on [Google Groups - Drools Usage|https://groups.google.com/forum/?fromgroups#!topic/drools-usage/G7r...] and as requested by Mario Fusco... > We currently have a ruleset that relies heavily on Map facts. In Drools 6.5 we fire approximately 400 rules. > In Drools 7.0 we get only about 50 rules unless we add the "<property key="drools.propertySpecific" value="ALLOWED"/>" to the kmodule.xml, in which case we fire the full 400 rules or by using @Watch(*) or @Watch(!*) on the rules. It "seems" like only the first evaluations of the rules are firing and then no others after that. > Our flow generally follows something like below, within a stateful session, using rules only. We fire all rules per-request then close the session. > Watch for changes to the Map properties > If a certain property or properties exist a 'populate' rule fires (calls modify()) > The populate rule enriches the map fact. (calls modify()) > Based on #3, more rules fire when certain properties exist (calls modify()) > We are work heavily with rules that depend on loaded available facts up-front and computed properties throughout evaluation. > I have a couple of usage questions regarding Drools 7, the default enabling of Property Reactive and using Maps as the facts: > In general, how do maps work with property reactive and respond to modify/insert events? Does Drools look at the Map as a whole, any change re-evaluates the tree, or each individual property within the map re-evaluates the change? > In Drools 7, by defaulting the property reactive setting, does that mean all rules need to be annotated or they should they work as is (dao or map-based facts) when using modify/insert? > For reference, we are relying on this doco https://docs.jboss.org/drools/release/7.0.0.Final/drools-docs/html_single.... > I am looking into details or an example how to properly use Maps in Drools 7 with Property Reactive features always enabled (as suggested per the doco).... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

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 June 2017