June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8990) Add unit test for CLI Capability completion

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFLY-8990: ------------------------------------------ Summary: Add unit test for CLI Capability completion Key: WFLY-8990 URL: https://issues.jboss.org/browse/WFLY-8990 Project: WildFly Issue Type: Task Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise That is a follow up for WFCORE-2993. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2998) levelRange in filter-spec is documented wrong and makes Wildfly startup fail silently

by Gregor Rosenauer (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2998?page=com.atlassian.jira.plugi... ] Gregor Rosenauer commented on WFCORE-2998: ------------------------------------------ thanks for the quick response to this issue! [~jamezp] please note that the more serious issue is that a wrong order of levels *breaks* deployment and the entire app server just exits with an error code 1. There is nothing in the logs, it just dies. This should not happen. Instead, Wildfly should report a configuration error and switch to default, logging all levels. > levelRange in filter-spec is documented wrong and makes Wildfly startup fail silently > ------------------------------------------------------------------------------------- > > Key: WFCORE-2998 > URL: https://issues.jboss.org/browse/WFCORE-2998 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Affects Versions: 2.2.1.Final > Reporter: Gregor Rosenauer > Assignee: James Perkins > Labels: check, configuration, logging, startup > > Linux 4.8.0-54-generic #57-Ubuntu SMP Wed May 24 10:21:44 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux > Oracle JDK 8 build 1.8.0_131-b11 > running in a docker container using Docker 1.12.6, build 78d1802 > Trying to configure e.g. a console-appender with a logging filter as described in > [Wildfly 10 Logging Configuration|https://docs.jboss.org/author/display/WFLY10/Logging+Config...] > The server will startup and happily parse the configuration, but then exit without any error: > {{2017-06-22 15:12:28,185 DEBG fd 7 closed, stopped monitoring <POutputDispatcher at 140706226583888 for <Subprocess at 140706228894320 with name wildfly in state RUNNING> (stdout)> > 2017-06-22 15:12:28,186 DEBG fd 9 closed, stopped monitoring <POutputDispatcher at 140706226584392 for <Subprocess at 140706228894320 with name wildfly in state RUNNING> (stderr)>}} > The culprit is the *order* of the levels in the range expression, which is the wrong way around. > The correct order (which makes more sense anyway) is e.g. {{[DEBUG,WARN)}} not {{[WARN,DEBUG)}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2998) levelRange in filter-spec is documented wrong and makes Wildfly startup fail silently

by Gregor Rosenauer (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2998?page=com.atlassian.jira.plugi... ] Gregor Rosenauer edited comment on WFCORE-2998 at 6/23/17 5:30 AM: ------------------------------------------------------------------- thanks for the quick response to this issue! [~jamezp] please note that the more serious issue is that a wrong order of levels *breaks* server startup and the entire app server just exits with an error code 1. There is nothing in the logs, it just dies. This should not happen. Instead, Wildfly should report a configuration error and switch to default, logging all levels. was (Author: grexe): thanks for the quick response to this issue! [~jamezp] please note that the more serious issue is that a wrong order of levels *breaks* deployment and the entire app server just exits with an error code 1. There is nothing in the logs, it just dies. This should not happen. Instead, Wildfly should report a configuration error and switch to default, logging all levels. > levelRange in filter-spec is documented wrong and makes Wildfly startup fail silently > ------------------------------------------------------------------------------------- > > Key: WFCORE-2998 > URL: https://issues.jboss.org/browse/WFCORE-2998 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Affects Versions: 2.2.1.Final > Reporter: Gregor Rosenauer > Assignee: James Perkins > Labels: check, configuration, logging, startup > > Linux 4.8.0-54-generic #57-Ubuntu SMP Wed May 24 10:21:44 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux > Oracle JDK 8 build 1.8.0_131-b11 > running in a docker container using Docker 1.12.6, build 78d1802 > Trying to configure e.g. a console-appender with a logging filter as described in > [Wildfly 10 Logging Configuration|https://docs.jboss.org/author/display/WFLY10/Logging+Config...] > The server will startup and happily parse the configuration, but then exit without any error: > {{2017-06-22 15:12:28,185 DEBG fd 7 closed, stopped monitoring <POutputDispatcher at 140706226583888 for <Subprocess at 140706228894320 with name wildfly in state RUNNING> (stdout)> > 2017-06-22 15:12:28,186 DEBG fd 9 closed, stopped monitoring <POutputDispatcher at 140706226584392 for <Subprocess at 140706228894320 with name wildfly in state RUNNING> (stderr)>}} > The culprit is the *order* of the levels in the range expression, which is the wrong way around. > The correct order (which makes more sense anyway) is e.g. {{[DEBUG,WARN)}} not {{[WARN,DEBUG)}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-121) Manual Testcases - Create and Run

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-121?page=com.atlassian.jira.pl... ] Hayk Hovsepyan commented on HAWKULARQE-121: ------------------------------------------- Manual testcases are created and documented in https://mojo.redhat.com/docs/DOC-1141237 > Manual Testcases - Create and Run > --------------------------------- > > Key: HAWKULARQE-121 > URL: https://issues.jboss.org/browse/HAWKULARQE-121 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1261) Revisit credentials key-store-reference and certificate from Elytron client configuration file

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-1261?page=com.atlassian.jira.plugin.s... ] Ondrej Lukas updated ELY-1261: ------------------------------ Affects Version/s: 1.1.0.Beta52 > Revisit credentials key-store-reference and certificate from Elytron client configuration file > ---------------------------------------------------------------------------------------------- > > Key: ELY-1261 > URL: https://issues.jboss.org/browse/ELY-1261 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta52 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > It seems that only supported SASL mechanism in Elytron which is able to work with key/certificate is {{EXTERNAL}} mechanism. However this mechanism takes this information from SSL connection which means that credentials defined in {{configuration.authentication-client.authentication-configurations.configuration.credentials.key-store-reference}} or {{configuration.authentication-client.authentication-configurations.configuration.credentials.certificate}} from Elytron client configuration file are not used in this case. > Is there any Elytron supported SASL mechanism which is currently able to work with these credentials? In this case please provide configuration and SASL mechanism which is able to work with {{key-store-reference}} and {{certificate}} credentials. > Otherwise these {{key-store-reference}} and {{certificate}} should be removed from Elytron client configuration because they currently cannot be used by users (or tested by QA). They can be added to configuration again once Elytron will support mechanism which is able to work with key/certificate as credentials. This is basically the similar issue as JBEAP-11720. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1261) Revisit credentials key-store-reference and certificate from Elytron client configuration file

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-1261?page=com.atlassian.jira.plugin.s... ] Ondrej Lukas updated ELY-1261: ------------------------------ Description: It seems that only supported SASL mechanism in Elytron which is able to work with key/certificate is {{EXTERNAL}} mechanism. However this mechanism takes this information from SSL connection which means that credentials defined in {{configuration.authentication-client.authentication-configurations.configuration.credentials.key-store-reference}} or {{configuration.authentication-client.authentication-configurations.configuration.credentials.certificate}} from Elytron client configuration file are not used in this case. Is there any Elytron supported SASL mechanism which is currently able to work with these credentials? In this case please provide configuration and SASL mechanism which is able to work with {{key-store-reference}} and {{certificate}} credentials. Otherwise these {{key-store-reference}} and {{certificate}} should be removed from Elytron client configuration because they currently cannot be used by users (or tested by QA). They can be added to configuration again once Elytron will support mechanism which is able to work with key/certificate as credentials. This is basically the similar issue as ELY-1257. was: It seems that only supported SASL mechanism in Elytron which is able to work with key/certificate is {{EXTERNAL}} mechanism. However this mechanism takes this information from SSL connection which means that credentials defined in {{configuration.authentication-client.authentication-configurations.configuration.credentials.key-store-reference}} or {{configuration.authentication-client.authentication-configurations.configuration.credentials.certificate}} from Elytron client configuration file are not used in this case. Is there any Elytron supported SASL mechanism which is currently able to work with these credentials? In this case please provide configuration and SASL mechanism which is able to work with {{key-store-reference}} and {{certificate}} credentials. Otherwise these {{key-store-reference}} and {{certificate}} should be removed from Elytron client configuration because they currently cannot be used by users (or tested by QA). They can be added to configuration again once Elytron will support mechanism which is able to work with key/certificate as credentials. This is basically the similar issue as JBEAP-11720. > Revisit credentials key-store-reference and certificate from Elytron client configuration file > ---------------------------------------------------------------------------------------------- > > Key: ELY-1261 > URL: https://issues.jboss.org/browse/ELY-1261 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta52 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > It seems that only supported SASL mechanism in Elytron which is able to work with key/certificate is {{EXTERNAL}} mechanism. However this mechanism takes this information from SSL connection which means that credentials defined in {{configuration.authentication-client.authentication-configurations.configuration.credentials.key-store-reference}} or {{configuration.authentication-client.authentication-configurations.configuration.credentials.certificate}} from Elytron client configuration file are not used in this case. > Is there any Elytron supported SASL mechanism which is currently able to work with these credentials? In this case please provide configuration and SASL mechanism which is able to work with {{key-store-reference}} and {{certificate}} credentials. > Otherwise these {{key-store-reference}} and {{certificate}} should be removed from Elytron client configuration because they currently cannot be used by users (or tested by QA). They can be added to configuration again once Elytron will support mechanism which is able to work with key/certificate as credentials. This is basically the similar issue as ELY-1257. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1261) Revisit credentials key-store-reference and certificate from Elytron client configuration file

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-1261: --------------------------------- Summary: Revisit credentials key-store-reference and certificate from Elytron client configuration file Key: ELY-1261 URL: https://issues.jboss.org/browse/ELY-1261 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical It seems that only supported SASL mechanism in Elytron which is able to work with key/certificate is {{EXTERNAL}} mechanism. However this mechanism takes this information from SSL connection which means that credentials defined in {{configuration.authentication-client.authentication-configurations.configuration.credentials.key-store-reference}} or {{configuration.authentication-client.authentication-configurations.configuration.credentials.certificate}} from Elytron client configuration file are not used in this case. Is there any Elytron supported SASL mechanism which is currently able to work with these credentials? In this case please provide configuration and SASL mechanism which is able to work with {{key-store-reference}} and {{certificate}} credentials. Otherwise these {{key-store-reference}} and {{certificate}} should be removed from Elytron client configuration because they currently cannot be used by users (or tested by QA). They can be added to configuration again once Elytron will support mechanism which is able to work with key/certificate as credentials. This is basically the similar issue as JBEAP-11720. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1630) DMN support during incremental KieContainer upgrade

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1630?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1630: ----------------------------------- Priority: Critical (was: Major) > DMN support during incremental KieContainer upgrade > --------------------------------------------------- > > Key: DROOLS-1630 > URL: https://issues.jboss.org/browse/DROOLS-1630 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Critical > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1622) NPE when compiling DMN file from test DMNRuntimeTest.testNoPrefix on IBM JDK

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1622?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1622: ----------------------------------- Priority: Critical (was: Major) > NPE when compiling DMN file from test DMNRuntimeTest.testNoPrefix on IBM JDK > ---------------------------------------------------------------------------- > > Key: DROOLS-1622 > URL: https://issues.jboss.org/browse/DROOLS-1622 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.0.0.Final > Reporter: Tibor Zimányi > Assignee: Matteo Mortari > Priority: Critical > Labels: reported-by-qe > Fix For: 7.1.0.Final > > > When running test [1] on IBM JDK, the test fails with this output [2]. > [1] https://github.com/kiegroup/drools/blob/32822e243a237cf26f26830a895035b97... > [2] https://gist.github.com/baldimir/969bd8f72665ff0e4244350abaed1ef4 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1622) NPE when compiling DMN file from test DMNRuntimeTest.testNoPrefix on IBM JDK

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1622?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1622: ----------------------------------- Sprint: 2017 Week 26-27 > NPE when compiling DMN file from test DMNRuntimeTest.testNoPrefix on IBM JDK > ---------------------------------------------------------------------------- > > Key: DROOLS-1622 > URL: https://issues.jboss.org/browse/DROOLS-1622 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.0.0.Final > Reporter: Tibor Zimányi > Assignee: Matteo Mortari > Priority: Critical > Labels: reported-by-qe > Fix For: 7.1.0.Final > > > When running test [1] on IBM JDK, the test fails with this output [2]. > [1] https://github.com/kiegroup/drools/blob/32822e243a237cf26f26830a895035b97... > [2] https://gist.github.com/baldimir/969bd8f72665ff0e4244350abaed1ef4 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 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 June 2017