May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3899) Upgrade to JBoss Logging 1.0.2.Final

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3899?page=com.atlassian.jira.plugi... ] Jeff Mesnil reopened WFCORE-3899: --------------------------------- > Upgrade to JBoss Logging 1.0.2.Final > ------------------------------------ > > Key: WFCORE-3899 > URL: https://issues.jboss.org/browse/WFCORE-3899 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Logging > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3899) Upgrade to JBoss Logging 1.0.2.Final

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3899?page=com.atlassian.jira.plugi... ] Jeff Mesnil closed WFCORE-3899. ------------------------------- Resolution: Rejected > Upgrade to JBoss Logging 1.0.2.Final > ------------------------------------ > > Key: WFCORE-3899 > URL: https://issues.jboss.org/browse/WFCORE-3899 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Logging > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3899) Upgrade to JBoss Logging 1.0.2.Final

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFCORE-3899: ----------------------------------- Summary: Upgrade to JBoss Logging 1.0.2.Final Key: WFCORE-3899 URL: https://issues.jboss.org/browse/WFCORE-3899 Project: WildFly Core Issue Type: Component Upgrade Components: Logging Reporter: Jeff Mesnil Assignee: Jeff Mesnil -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2086) Intermittent failure in OperationCancellationTestCase

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2086?page=com.atlassian.jira.plugi... ] Richard Opalka edited comment on WFCORE-2086 at 5/31/18 12:30 PM: ------------------------------------------------------------------ I am also aware of this problem but didn't have time to analyze it. What I know about this issue is it was introduced with this commit: --- [blackhole][/home/opalka/git/redhat/wildfly-core]>git log -1 remotes/origin/failing-10-runs-9-failures commit 9bd9d19bbd39a06743b5434a8de14cd125d76294 (origin/failing-10-runs-9-failures) Author: David M. Lloyd <david.lloyd(a)redhat.com> Date: Thu Nov 2 13:38:14 2017 -0500 [WFCORE-3397] Introduce new thread pool into AbstractModelControllerOperationHandlerFactoryService --- was (Author: ropalka): I am also aware of this problem but didn't have time to analyze it. What I know about this issue is it was introduced with this commit: --- [blackhole][/home/opalka/git/redhat/wildfly-core]>git log -1 remotes/origin/failing-10-runs-1-failures commit 5145712087c9ae0625fc8c730e924967ecff9d83 (origin/failing-10-runs-1-failures) Author: David M. Lloyd <david.lloyd(a)redhat.com> Date: Thu Nov 2 08:51:12 2017 -0500 [WFCORE-3397] Introduce new thread pool to (deprecated) model controller client configuration factory --- > Intermittent failure in OperationCancellationTestCase > ----------------------------------------------------- > > Key: WFCORE-2086 > URL: https://issues.jboss.org/browse/WFCORE-2086 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 5.0.0.Beta5 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > Investigate this: > https://ci.wildfly.org/viewLog.html?buildId=36108&buildTypeId=WildFlyCore... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2086) Intermittent failure in OperationCancellationTestCase

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2086?page=com.atlassian.jira.plugi... ] Richard Opalka commented on WFCORE-2086: ---------------------------------------- I am also aware of this problem but didn't have time to analyze it. What I know about this issue is it was introduced with this commit: --- [blackhole][/home/opalka/git/redhat/wildfly-core]>git log -1 remotes/origin/failing-10-runs-1-failures commit 5145712087c9ae0625fc8c730e924967ecff9d83 (origin/failing-10-runs-1-failures) Author: David M. Lloyd <david.lloyd(a)redhat.com> Date: Thu Nov 2 08:51:12 2017 -0500 [WFCORE-3397] Introduce new thread pool to (deprecated) model controller client configuration factory --- > Intermittent failure in OperationCancellationTestCase > ----------------------------------------------------- > > Key: WFCORE-2086 > URL: https://issues.jboss.org/browse/WFCORE-2086 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 5.0.0.Beta5 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > Investigate this: > https://ci.wildfly.org/viewLog.html?buildId=36108&buildTypeId=WildFlyCore... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1584) Add ability to log security manager violations to out-of-band log file

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-1584?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on ELY-1584: ---------------------------------- [~honza889] it might be sufficient. Mainly we'd want to see if it is possible to create a log of failures from the test suite (without missing anything, which is a challenge as each module may have a different logging configuration). And we'd want to ensure that the logged permission violations do not change unexpectedly from one test run to the next. Part of the challenge is that things do not always run in order though, so we might need a special comparison tool for this. I was thinking that it might even be a good idea to have options for a specialized format which can be easily machine-parsed which includes the permission, the PD, and the stack trace. > Add ability to log security manager violations to out-of-band log file > ---------------------------------------------------------------------- > > Key: ELY-1584 > URL: https://issues.jboss.org/browse/ELY-1584 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Security Manager > Reporter: David Lloyd > > It would be useful for CI if we could set a system property which would log security manager permission check violations (and the details thereof) to a log file, outside of the standard log infrastructure. This would potentially allow us to fail CI when unexpected "hidden" permission violations occur by way of a post-build script analyzes the log output. > This might also be useful for troubleshooting more obscure security manager related problems. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1572) japicmp force source compatibility, but only binary compatibility is required

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1572?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1572: ---------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/1145 (was: https://github.com/wildfly-security/wildfly-elytron/pull/1134) > japicmp force source compatibility, but only binary compatibility is required > ----------------------------------------------------------------------------- > > Key: ELY-1572 > URL: https://issues.jboss.org/browse/ELY-1572 > Project: WildFly Elytron > Issue Type: Bug > Components: Build > Affects Versions: 1.3.0.Final > Reporter: Jan Kalina > Assignee: Jan Kalina > Fix For: 1.4.0.CR1 > > > As part of ELY-1523 japicmp was configured to force binary and source compatibility. > By last discussion, only binary compatibility is required. > {panel} > *Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible... > *Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people > {panel} > Japicmp currently reports adding default method into interface as source incompatible change (see https://github.com/siom79/japicmp/issues/201) -> blocks adding IV into MaskedPassword in ELY-867 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10439) Modernize mod_cluster subsystem

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10439?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-10439: ---------------------------------- Affects Version/s: 13.0.0.Final (was: 13.0.0.Beta1) > Modernize mod_cluster subsystem > ------------------------------- > > Key: WFLY-10439 > URL: https://issues.jboss.org/browse/WFLY-10439 > Project: WildFly > Issue Type: Task > Components: mod_cluster > Affects Versions: 12.0.0.Final, 13.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 14.0.0.CR1 > > > In order to support further subsystem development, specifically WFLY-6803, the subsystem needs to be modernized. While doing so, multiple issues are being uncovered. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1444) Jdbc-realm with simple digest mapper

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1444?page=com.atlassian.jira.plugin.s... ] Jan Kalina resolved ELY-1444. ----------------------------- Fix Version/s: 1.4.0.CR1 Assignee: Jan Kalina Resolution: Duplicate Issue Support of hex encoding added in ELY-1582. > Jdbc-realm with simple digest mapper > ------------------------------------ > > Key: ELY-1444 > URL: https://issues.jboss.org/browse/ELY-1444 > Project: WildFly Elytron > Issue Type: Bug > Components: Passwords > Affects Versions: 1.2.0.Beta9 > Reporter: Martin Choma > Assignee: Jan Kalina > Fix For: 1.4.0.CR1 > > > This is inspired by ELY-1435, but in this case trying simple digest hash. > In db is stored this sha-256 password hash: 5E884898DA28047151D0E56F8DC6292773603D0D6AABBDD62A11EF721D1542D8 > I get these values by http://passwordsgenerator.net/sha256-hash-generator/ > {noformat} > 17:30:50,211 DEBUG [org.wildfly.security] (default task-3) Using UsernamePasswordAuthenticationMechanism for username authentication. Realm: [Some Realm], Username: [correctUser]. > 17:30:50,211 TRACE [org.wildfly.security] (default task-3) Handling RealmCallback: selected = [Some Realm] > 17:30:50,212 TRACE [org.wildfly.security] (default task-3) Handling NameCallback: authenticationName = correctUser > 17:30:50,212 TRACE [org.wildfly.security] (default task-3) Principal assigning: [correctUser], pre-realm rewritten: [correctUser], realm name: [jdbc-realm], post-realm rewritten: [correctUser], realm rewritten: [correctUser] > 17:30:50,215 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD FROM USERS WHERE NAME = ? with value correctUser > 17:30:50,301 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT roles.name FROM users, roles, users_roles WHERE users.name=? AND users.id = users_roles.userid AND roles.id = users_roles.roleid with value correctUser > 17:30:50,306 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD FROM USERS WHERE NAME = ? with value correctUser > 17:30:50,324 DEBUG [org.wildfly.security] (default task-3) User correctUser authentication failed. > 17:30:50,324 TRACE [org.wildfly.security] (default task-3) Handling AuthenticationCompleteCallback: fail > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6803) Add multi-server support to mod_cluster

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6803?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6803: --------------------------------- Affects Version/s: 13.0.0.Final 12.0.0.Final 11.0.0.Final > Add multi-server support to mod_cluster > --------------------------------------- > > Key: WFLY-6803 > URL: https://issues.jboss.org/browse/WFLY-6803 > Project: WildFly > Issue Type: Feature Request > Components: mod_cluster > Affects Versions: 10.0.0.Final, 11.0.0.Final, 12.0.0.Final, 13.0.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Fix For: 14.0.0.CR1 > > > Currently, mod_cluster subsystem supports only a single configuration, which references the default undertow server. However, Undertow supports multiple servers, and exposes a distinct route capability per server (see WFLY-6778). mod_cluster should therefore support multiple "profiles", where each profile references a specific undertow server. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2018