October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1773) JDK 9: Trait tests fail on invokevirtual codes

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1773?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-1773: ---------------------------------- Summary: JDK 9: Trait tests fail on invokevirtual codes (was: JDK 9: Trait tests fails on invokevirtual codes) > JDK 9: Trait tests fail on invokevirtual codes > ---------------------------------------------- > > Key: DROOLS-1773 > URL: https://issues.jboss.org/browse/DROOLS-1773 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.4.1.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > > When Drools repository tests are executed with JDK 9, some of them fail [1]. As you can see, there are currently 2 main areas that fail. > - Traits - fail on some invokevirtual codes > - Persistence tests failing due to XML APIs not being part of default JDK modules anymore in JDK 9 > Please see the linked spreadsheet for more information. I expect that these 2 areas hide some other problems that we will need to solve later. > [1] https://docs.google.com/a/redhat.com/spreadsheets/d/1acFYb9utXhHb3KU2t3Fn... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1773) JDK 9: Trait test fails on invokevirtual codes

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1773?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-1773: ---------------------------------- Summary: JDK 9: Trait test fails on invokevirtual codes (was: Some Drools tests fail with JDK 9) > JDK 9: Trait test fails on invokevirtual codes > ---------------------------------------------- > > Key: DROOLS-1773 > URL: https://issues.jboss.org/browse/DROOLS-1773 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.4.1.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > > When Drools repository tests are executed with JDK 9, some of them fail [1]. As you can see, there are currently 2 main areas that fail. > - Traits - fail on some invokevirtual codes > - Persistence tests failing due to XML APIs not being part of default JDK modules anymore in JDK 9 > Please see the linked spreadsheet for more information. I expect that these 2 areas hide some other problems that we will need to solve later. > [1] https://docs.google.com/a/redhat.com/spreadsheets/d/1acFYb9utXhHb3KU2t3Fn... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1773) JDK 9: Trait tests fails on invokevirtual codes

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1773?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-1773: ---------------------------------- Summary: JDK 9: Trait tests fails on invokevirtual codes (was: JDK 9: Trait test fails on invokevirtual codes) > JDK 9: Trait tests fails on invokevirtual codes > ----------------------------------------------- > > Key: DROOLS-1773 > URL: https://issues.jboss.org/browse/DROOLS-1773 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.4.1.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > > When Drools repository tests are executed with JDK 9, some of them fail [1]. As you can see, there are currently 2 main areas that fail. > - Traits - fail on some invokevirtual codes > - Persistence tests failing due to XML APIs not being part of default JDK modules anymore in JDK 9 > Please see the linked spreadsheet for more information. I expect that these 2 areas hide some other problems that we will need to solve later. > [1] https://docs.google.com/a/redhat.com/spreadsheets/d/1acFYb9utXhHb3KU2t3Fn... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1775) JDK 9: JavaBackendTypeTest.testPerson fails on ConcurrentModificationException

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1775?page=com.atlassian.jira.plugi... ] Tibor Zimányi commented on DROOLS-1775: --------------------------------------- [~tirelli] mentioning you so you are also aware of this issue. > JDK 9: JavaBackendTypeTest.testPerson fails on ConcurrentModificationException > ------------------------------------------------------------------------------ > > Key: DROOLS-1775 > URL: https://issues.jboss.org/browse/DROOLS-1775 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.4.1.Final > Reporter: Tibor Zimányi > Assignee: Matteo Mortari > > When test JavaBackendTypeTest.testPerson from kie-dmn-feel module is run on JDK 9, it fails on ConcurrentModificationException with the following stacktrace [1]. > [1] https://gist.github.com/baldimir/d19c772ae170546047bd4f9fa6c80dd6 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1775) JDK 9: JavaBackendTypeTest.testPerson fails on ConcurrentModificationException

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-1775: ------------------------------------- Summary: JDK 9: JavaBackendTypeTest.testPerson fails on ConcurrentModificationException Key: DROOLS-1775 URL: https://issues.jboss.org/browse/DROOLS-1775 Project: Drools Issue Type: Bug Components: dmn engine Affects Versions: 7.4.1.Final Reporter: Tibor Zimányi Assignee: Matteo Mortari When test JavaBackendTypeTest.testPerson from kie-dmn-feel module is run on JDK 9, it fails on ConcurrentModificationException with the following stacktrace [1]. [1] https://gist.github.com/baldimir/d19c772ae170546047bd4f9fa6c80dd6 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1774) JDK 9: Drools persistence tests fail on ClassNotFoundException: JAXBException

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-1774: ------------------------------------- Summary: JDK 9: Drools persistence tests fail on ClassNotFoundException: JAXBException Key: DROOLS-1774 URL: https://issues.jboss.org/browse/DROOLS-1774 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.4.1.Final Reporter: Tibor Zimányi Assignee: Petr Široký When tests from drools-persistence-jpa module are run with JDK 9, the tests fail with this stacktrace [1]. It is probably due to xml apis not being part of default Java 9 modules. To see all failing test in the persistence module, please see this spreadsheet [2]. [1] https://gist.github.com/baldimir/76bff4a7a5ad3786f865cc7d0eb59efe [2] https://docs.google.com/a/redhat.com/spreadsheets/d/1acFYb9utXhHb3KU2t3Fn... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9477) Cannot create two hosts with unspecified default web module in Undertow

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9477?page=com.atlassian.jira.plugin.... ] Tomaz Cerar moved JBEAP-13612 to WFLY-9477: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-9477 (was: JBEAP-13612) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Web (Undertow) (was: User Experience) (was: Web (Undertow)) Affects Version/s: 11.0.0.Final (was: 7.1.0.DR7) > Cannot create two hosts with unspecified default web module in Undertow > ----------------------------------------------------------------------- > > Key: WFLY-9477 > URL: https://issues.jboss.org/browse/WFLY-9477 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 11.0.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Minor > > As a user, I cannot create two hosts with unspecified default web module. Currently the default-web-module is checked only for uniqueness and by default there is defined ROOT.war, which by default doesn't exist. Current behavior is that in case of non existing module defined by default-web-module, when accessing the root context ('/'), the content defined as part of welcome-file handler is provided. > As a user I should not be forced to put random values to avoid duplicity check, when I don't want to have set default-web-module. As such the default-web-module should have undefined default which could be checked and avoided failures due duplicates as there are in reality none. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3201) Add JaCoCo profile to wf-core TS

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3201?page=com.atlassian.jira.plugi... ] Marek Kopecký updated WFCORE-3201: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2736 > Add JaCoCo profile to wf-core TS > -------------------------------- > > Key: WFCORE-3201 > URL: https://issues.jboss.org/browse/WFCORE-3201 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Marek Kopecký > Assignee: Marek Kopecký > > Add JaCoCo profile to wf-core TS -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-991) SASL Digest client handles callbacks incorrectly

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-991?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-991: ------------------------------ Assignee: Jan Kalina > SASL Digest client handles callbacks incorrectly > ------------------------------------------------ > > Key: ELY-991 > URL: https://issues.jboss.org/browse/ELY-991 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms, SASL > Reporter: David Lloyd > Assignee: Jan Kalina > > Right now the SASL digest client handles callbacks like this: > * If a realm choice is available use RealmChoiceCallback to get it, and fail if it is not supported > * Try to use RealmCallback+NameCallback+CredentialCallback (with digest password) > * Try to use RealmCallback+NameCallback+CredentialCallback (with two-way password) > * Try to use RealmCallback+NameCallback+PasswordCallback > This is a problem because RealmChoiceCallback should not be required, and if it was supported, RealmCallback is not needed. It's basically OK to retry realm selection and name selection if the credential was unsupported. > The logic should probably be more like this: > * Try to use <a realm callback>+NameCallback+CredentialCallback (with digest password) > ** First try with RealmChoiceCallback if there is a choice > ** Then try with RealmCallback if RealmChoiceCallback is unsupported > ** If there is no default realm, fail > ** Otherwise try with no realm callback and use the default realm > * Try to use <a realm callback>+NameCallback+CredentialCallback (with two-way password) > ** First try with RealmChoiceCallback if it was not eliminated above and there is a choice > ** Then try RealmCallback if it was not eliminated above > ** If there is no default realm, fail > ** Otherwise try with no realm callback and use the default realm > * Try to use <a realm callback>+NameCallback+PasswordCallback > ** First try with RealmChoiceCallback if it was not eliminated above and there is a choice > ** Then try RealmCallback if it was not eliminated above > ** If there is no default realm, fail > ** Otherwise try with no realm callback and use the default realm > This way we don't retry callbacks that don't work, and we don't fail if RealmCallback is not supported. If no user name or credential is given, then the attempt should be considered a failure and the next credential tried without eliminating any realm callbacks. If no realm is given then the attempt should be a failure without trying other realm callback options, because the callback is supported but there was no realm given (which is a programming error). > If a user name or realm is given in an earlier stage, it should stay as the default for later stages. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-742) SASL client mechs should use javax.security.sasl.AuthenticationException where appropriate

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-742?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-742: ------------------------------ Fix Version/s: 1.1.0.Alpha1 Assignee: David Lloyd Resolution: Done > SASL client mechs should use javax.security.sasl.AuthenticationException where appropriate > ------------------------------------------------------------------------------------------ > > Key: ELY-742 > URL: https://issues.jboss.org/browse/ELY-742 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Mechanisms, SASL > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Minor > Fix For: 1.1.0.Alpha1 > > > There is a specific exception type which indicates that a SASL authentication has failed as opposed to a protocol/transit or operational problem. We should use that whenever appropriate. > This means we'd need to add a {{toSaslAuthenticationException()}} method to {{org.wildfly.security.mechanism.AuthenticationMechanismException}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

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