January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3386) Add configuration required to support JASPIC to the Elytron subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3386?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3386: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > Add configuration required to support JASPIC to the Elytron subsystem > --------------------------------------------------------------------- > > Key: WFCORE-3386 > URL: https://issues.jboss.org/browse/WFCORE-3386 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3382) Further Enhance Elytron Permission Configuration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3382?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3382: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > Further Enhance Elytron Permission Configuration > ------------------------------------------------ > > Key: WFCORE-3382 > URL: https://issues.jboss.org/browse/WFCORE-3382 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Fix For: 4.0.0.Beta1 > > > This has currently been simplified to a single resource for the out of the box configuration, however this brings issues as now permissions are duplicated so modifications need to be replicated instead of to a single location. > Finding a way for the default required permissions to be defined in one location could help eliminate the duplication. > We could also consider going one step further and subsystems register the default permissions that should be granted. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3360) Eliminate org.wildfly.extension.elytron.ProviderUtil

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3360?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3360: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > Eliminate org.wildfly.extension.elytron.ProviderUtil > ---------------------------------------------------- > > Key: WFCORE-3360 > URL: https://issues.jboss.org/browse/WFCORE-3360 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Beta1 > > > WildFly Elytron contains a public utility class org.wildfly.security.util.ProviderUtil for the same purpose, we should use the code within WildFly Elytron and not custom code within the subsystem. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3255) Complex type AttributeDefinition variants don't handle ParameterCorrector properly

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3255?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3255: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > Complex type AttributeDefinition variants don't handle ParameterCorrector properly > ---------------------------------------------------------------------------------- > > Key: WFCORE-3255 > URL: https://issues.jboss.org/browse/WFCORE-3255 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.1.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 4.0.0.Beta1 > > > If a field in a complex attribute (i.e. one that uses Object...AttributeDefinition) has a ParameterCorrector configured, that corrector never gets called. That's because only a corrector on the top level attribute gets called. > These classes should automatically use an internal corrector that first calls any corrector configured for fields, and then, if one is present, calls any top level corrector. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3542) Elytron JDBC realm password mapping is not consistent with underlying implementation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3542?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3542: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > Elytron JDBC realm password mapping is not consistent with underlying implementation > ------------------------------------------------------------------------------------ > > Key: WFCORE-3542 > URL: https://issues.jboss.org/browse/WFCORE-3542 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: David Lloyd > Assignee: Darran Lofthouse > Fix For: 4.0.0.Beta1 > > > There is no way to configure the JDBC realm to use modular crypt in WildFly, even though the underlying realm does support it. > The problem is that the {{salt-index}} and {{itereration-count-index}} attributes should be optional, and if they not given, a value of {{-1}} should be passed to the mapper. By omitting both of these values, the database column values will then be recognized as modular-crypt strings. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3527) Remove OSGi obsolete code

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3527?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3527: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > Remove OSGi obsolete code > ------------------------- > > Key: WFCORE-3527 > URL: https://issues.jboss.org/browse/WFCORE-3527 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Affects Versions: 4.0.0.Alpha5 > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 4.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3519) Add JASPI Module

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3519?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3519: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > Add JASPI Module > ---------------- > > Key: WFCORE-3519 > URL: https://issues.jboss.org/browse/WFCORE-3519 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Beta1 > > > (Copy from WildFly) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5332) Allow configure max-threads and core-threads independently. Allow idle thread reusage.

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-5332?page=com.atlassian.jira.plugin.... ] David Lloyd resolved WFLY-5332. ------------------------------- Fix Version/s: 12.0.0.Alpha1 Resolution: Done > Allow configure max-threads and core-threads independently. Allow idle thread reusage. > -------------------------------------------------------------------------------------- > > Key: WFLY-5332 > URL: https://issues.jboss.org/browse/WFLY-5332 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Panagiotis Sotiropoulos > Assignee: David Lloyd > Fix For: 12.0.0.Alpha1 > > Attachments: JBossThreadPoolExecutor.jpg, JBossThreadPoolReuseIdleThreadsExecutor.jpg, ModifiedJBossThreadPoolExecutorStateDiagram.jpg > > > Description of problem: > It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there. The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core. > ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java > I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem. > Additional desired functionality according to PRODMGT-1401: > "the desired functionality is to, when a new request arrives > and there is an idle thread, use that thread instead of creating a new > thread [up until max-threads]." -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2088) Enhance CLI to support Aesh Commands

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2088?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2088: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2946 (was: https://github.com/wildfly/wildfly-core/pull/2843) > Enhance CLI to support Aesh Commands > ------------------------------------ > > Key: WFCORE-2088 > URL: https://issues.jboss.org/browse/WFCORE-2088 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Fix For: 4.0.0.Alpha8 > > > In order to modernize the way to develop CLI commands, CLI needs to support commands developed with aesh 1.0 API. Aesh has been recently re-architectured to expose a Command Runtime that we can integrate in CLI. > The first immediate benefit of this integration is the ability to load aesh based commands exposed by extensions. > The patch command should be a candidate to validate this integration of aesh commands. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1489) Expose (un)registerNotificationHandler() on OperationContext

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1489?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1489: ------------------------------------- Fix Version/s: 4.0.0.Alpha8 (was: 4.0.0.Alpha7) > Expose (un)registerNotificationHandler() on OperationContext > ------------------------------------------------------------ > > Key: WFCORE-1489 > URL: https://issues.jboss.org/browse/WFCORE-1489 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Kabir Khan > Assignee: Jeff Mesnil > Fix For: 4.0.0.Alpha8 > > > Currently the only way to (un)register notifications is via the NotificationHandlerRegistration exposed by ModelController.getNotificationRegistry(). It would be nice to not have to install a service whose only purpose is to get hold of the ModelController from OSH's. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 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 January 2018