May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1078) Elytron MatchRule.toString() method throws StringIndexOutOfBoundsException

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1078?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1078: ---------------------------------- Fix Version/s: 1.1.0.Beta45 (was: 1.1.0.Beta44) > Elytron MatchRule.toString() method throws StringIndexOutOfBoundsException > -------------------------------------------------------------------------- > > Key: ELY-1078 > URL: https://issues.jboss.org/browse/ELY-1078 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta36 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta45 > > > In case when implementation of {{asString(StringBuilder b)}} for MatchRule does not change length of passed parameter (which is 0) then 'java.lang.StringIndexOutOfBoundsException: String index out of range: -1' is thrown for calling {{MatchRule.toString()}} due to calling {{StringBuilder.setLength(-1)}}. > e.g. MatchRule {{ALL}} in implementation {{asString(StringBuilder b)}} just returns passed parameter, which results to mentioned exception. > Thrown exception: > {code} > java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > at java.lang.AbstractStringBuilder.setLength(AbstractStringBuilder.java:180) > at java.lang.StringBuilder.setLength(StringBuilder.java:76) > at org.wildfly.security.auth.client.MatchRule.toString(MatchRule.java:581) > ... > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1073) Add support for kerberos security factory in AuthenticationConfiguration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1073?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1073: ---------------------------------- Fix Version/s: 1.1.0.Beta45 (was: 1.1.0.Beta44) > Add support for kerberos security factory in AuthenticationConfiguration > ------------------------------------------------------------------------ > > Key: ELY-1073 > URL: https://issues.jboss.org/browse/ELY-1073 > Project: WildFly Elytron > Issue Type: Task > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: 1.1.0.Beta45 > > > Authentication configuration should be able to use a kerberos security factory to obtain the GSSCredential and associated KerberosTicket for authentication. The CallbackHandler code should check for CredentialCallbacks of type GSSKerberosCredential and use the configured factory to retrieve the credential and associated ticket. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1172) Release WildFly Elytron 1.1.0.Beta44

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1172?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1172. ----------------------------------- Resolution: Done > Release WildFly Elytron 1.1.0.Beta44 > ------------------------------------ > > Key: ELY-1172 > URL: https://issues.jboss.org/browse/ELY-1172 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta44 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2825) Upgrade WildFly Elytron to 1.1.0.Beta44

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2825?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2825: ------------------------------------- Summary: Upgrade WildFly Elytron to 1.1.0.Beta44 (was: Upgrade WildFly Elytron to 1.1.0.Beta43) > Upgrade WildFly Elytron to 1.1.0.Beta44 > --------------------------------------- > > Key: WFCORE-2825 > URL: https://issues.jboss.org/browse/WFCORE-2825 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta22 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1115) Revisit the meaning of aggregate-principal-transformer

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1115?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1115: ---------------------------- Fix Version/s: 1.1.0.Beta44 (was: 1.1.0.Beta41) > Revisit the meaning of aggregate-principal-transformer > ------------------------------------------------------ > > Key: ELY-1115 > URL: https://issues.jboss.org/browse/ELY-1115 > Project: WildFly Elytron > Issue Type: Bug > Components: Utils > Affects Versions: 1.1.0.Beta38 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: management-model, principal-transformer > Fix For: 1.1.0.Beta44 > > > Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See: > * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that? > * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case? > * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used? > This issue is reported based on previous discussion with engineering. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1172) Release WildFly Elytron 1.1.0.Beta44

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1172: ------------------------------------- Summary: Release WildFly Elytron 1.1.0.Beta44 Key: ELY-1172 URL: https://issues.jboss.org/browse/ELY-1172 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta44 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1115) Revisit the meaning of aggregate-principal-transformer

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1115?page=com.atlassian.jira.plugin.s... ] Jan Kalina edited comment on ELY-1115 at 5/18/17 11:50 AM: ----------------------------------------------------------- Not implemented {{InvalidNameState.getMechanismRealmConfiguration()}} has caused new failure of RegexValidatingPrincipalTransformerTestCase - moving fix version from Beta41 to Beta44. was (Author: honza889): Not implemented {{InvalidNameState.getMechanismRealmConfiguration()}} has caused failure - moving fix version from Beta41 to Beta44. > Revisit the meaning of aggregate-principal-transformer > ------------------------------------------------------ > > Key: ELY-1115 > URL: https://issues.jboss.org/browse/ELY-1115 > Project: WildFly Elytron > Issue Type: Bug > Components: Utils > Affects Versions: 1.1.0.Beta38 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: management-model, principal-transformer > Fix For: 1.1.0.Beta41 > > > Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See: > * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that? > * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case? > * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used? > This issue is reported based on previous discussion with engineering. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1115) Revisit the meaning of aggregate-principal-transformer

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1115?page=com.atlassian.jira.plugin.s... ] Jan Kalina commented on ELY-1115: --------------------------------- Not implemented {{InvalidNameState.getMechanismRealmConfiguration()}} has caused failure - moving fix version from Beta41 to Beta44. > Revisit the meaning of aggregate-principal-transformer > ------------------------------------------------------ > > Key: ELY-1115 > URL: https://issues.jboss.org/browse/ELY-1115 > Project: WildFly Elytron > Issue Type: Bug > Components: Utils > Affects Versions: 1.1.0.Beta38 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: management-model, principal-transformer > Fix For: 1.1.0.Beta41 > > > Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See: > * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that? > * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case? > * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used? > This issue is reported based on previous discussion with engineering. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-123) Support java.util.function.Supplier as a valid bundle return type

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-123?page=com.atlassian.jira.plugi... ] James Perkins reassigned LOGTOOL-123: ------------------------------------- Assignee: James Perkins > Support java.util.function.Supplier as a valid bundle return type > ----------------------------------------------------------------- > > Key: LOGTOOL-123 > URL: https://issues.jboss.org/browse/LOGTOOL-123 > Project: Log Tool > Issue Type: Enhancement > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > Fix For: 2.1.0.Alpha3 > > > Since version 2.1.x now requires Java 8 a {{java.util.function.Supplier<String>}} and {{java.util.function.Supplier<? extends Throwable>>}} should be supported. These could be useful for things like > {code:java} > Optional.orElseThrow(BundleInterface.MESSAGES.notFound()) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2829) Expose the ProcessType via the ManagementResourceRegistration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2829?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2829: ------------------------------------- Description: An Extension needs to be usable both on a HostController (for registering the subsystem management model for use in domain profiles) and on a server. But the API exposed by the Extension can differ in the two cases, as there are no runtime services behind a domain profile resource, while there usually are behind a server resource. So the Extension implementation may need to behave differently depending on the type of process it is running in. To support this, the ExtensionContext provided to the Extension exposes the ProcessType. But this isn't particularly friendly, as that forces the Extension impl to provide that ProcessType to its ResourceDefinition impls, and those are typically created in a tree with the Extension impl only creating the root. So lots of custom constructors passing a ProcessType down the tree. If ManagementResourceRegistration exposed the ProcessType, then the ResourceDefinition impls could directly read it when deciding what attributes/operations/children/notifications to register. was: An Extension needs to be usable both on a HostController (for registering the subsystem management model for use in domain profiles) and on a server. But the API exposed by the Extension can differ in the two cases, as there are no runtime services behind a domain profile resource, while there usually are behind a server resource. So the Extension implementation needs to behave differently depending on the type of process it is running in. To support this, the ExtensionContext provided to the Extension exposes the ProcessType. But this isn't particularly friendly, as that forces the Extension impl to provide that ProcessType to its ResourceDefinition impls, and those are typically created in a tree with the Extension impl only creating the root. So lots of custom constructors passing a ProcessType down the tree. If ManagementResourceRegistration exposed the ProcessType, then the ResourceDefinition impls could directly read it when deciding what attributes/operations/children/notifications to register. > Expose the ProcessType via the ManagementResourceRegistration > ------------------------------------------------------------- > > Key: WFCORE-2829 > URL: https://issues.jboss.org/browse/WFCORE-2829 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > An Extension needs to be usable both on a HostController (for registering the subsystem management model for use in domain profiles) and on a server. But the API exposed by the Extension can differ in the two cases, as there are no runtime services behind a domain profile resource, while there usually are behind a server resource. So the Extension implementation may need to behave differently depending on the type of process it is running in. > To support this, the ExtensionContext provided to the Extension exposes the ProcessType. But this isn't particularly friendly, as that forces the Extension impl to provide that ProcessType to its ResourceDefinition impls, and those are typically created in a tree with the Extension impl only creating the root. So lots of custom constructors passing a ProcessType down the tree. > If ManagementResourceRegistration exposed the ProcessType, then the ResourceDefinition impls could directly read it when deciding what attributes/operations/children/notifications to register. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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