February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2365) Review custom-modifiable-realm resource in Elytron subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2365?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2365: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha9) > Review custom-modifiable-realm resource in Elytron subsystem > ------------------------------------------------------------ > > Key: WFCORE-2365 > URL: https://issues.jboss.org/browse/WFCORE-2365 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Fix For: 4.0.0.Beta1 > > > See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3073) Handle Shutdown via TERM gracefully

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3073: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha9) > Handle Shutdown via TERM gracefully > ----------------------------------- > > Key: WFCORE-3073 > URL: https://issues.jboss.org/browse/WFCORE-3073 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Ben Parees > Assignee: Brian Stansberry > Fix For: 4.0.0.Beta1 > > > The wildfly server currently -terminates immediately- performs a standard (non-graceful) shutdown in response to a TERM signal. To achieve a -clean- graceful shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved. > While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course). > Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3019) The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3019: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha9) > The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-3019 > URL: https://issues.jboss.org/browse/WFCORE-3019 > Project: WildFly Core > Issue Type: Task > Components: Server > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 4.0.0.Beta1 > > > For WFLY-4692 we moved the "product" stuff out of core-feature-pack and into dist. But this means it doesn't end up in the skinny dist produced by the "build" module. Plus it makes the "dist" a kind of FP of its own. > The stuff in dist/src/distribution should be its own FP. That one *perhaps* depends on core-feature-pack. Then build and dist use the new FP in addition to or instead of core-feature-pack. > So, core-feature-pack is independently usable, in other dists, but our offiical build/dist, which has our official product module, picks up the new FP. > Whether the new "product" FP depends on core-feature-pack depends on how we want to use it; i.e. can this bin/product.conf and module be used in some other flavor of dist. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3000) Allow turning the security manager on on a per jvm basis

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3000?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3000: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha9) > Allow turning the security manager on on a per jvm basis > -------------------------------------------------------- > > Key: WFCORE-3000 > URL: https://issues.jboss.org/browse/WFCORE-3000 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Labels: domain-mode > Fix For: 4.0.0.Beta1 > > > Turning on the security manager in a WildFly process is done by adding the -secmgr arg to org.jboss.modules.Main. But the jvm config settings in domain mode provide no mechanism for configuring args to Main; they only provide options for args to java. So there is no way to turn on the security manager for an individual jvm config (i.e. one or more servers) or if it is on for the HC there is no way to turn it off for a particular jvm config. > The jvm config needs an attribute for this; default is undefined which should be documented as meaning the setting is derived from the HC's settings (i.e. the way it is now.) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2953) Add a socket-handler resource to the logging subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2953?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2953: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha9) > Add a socket-handler resource to the logging subsystem > ------------------------------------------------------ > > Key: WFCORE-2953 > URL: https://issues.jboss.org/browse/WFCORE-2953 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 4.0.0.Beta1 > > > The logging subsystem should include a resource for a {{socket-handler}}. This will be useful for structured formatters, such as the [{{json-formatter}}|WFCORE-2951]. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2952) Add an XML formatter resources to the logging subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2952?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2952: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha9) > Add an XML formatter resources to the logging subsystem > ------------------------------------------------------- > > Key: WFCORE-2952 > URL: https://issues.jboss.org/browse/WFCORE-2952 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 4.0.0.Beta1 > > > The logging subsystem should include a resource for a {{xml-formatter}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2951) Add JSON formatter resources to the logging subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2951?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2951: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha9) > Add JSON formatter resources to the logging subsystem > ----------------------------------------------------- > > Key: WFCORE-2951 > URL: https://issues.jboss.org/browse/WFCORE-2951 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 4.0.0.Beta1 > > > The logging subsystem should include resources for a {{json-formatter}} -and probably a {{logstash-formatter}}. The {{logstash-formatter}} is likely just an extension of the {{json-formatter}} with some predefined attributes that logstash requires-. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2930) Support a socket-binding-group as a child of profile

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2930?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2930: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha9) > Support a socket-binding-group as a child of profile > ---------------------------------------------------- > > Key: WFCORE-2930 > URL: https://issues.jboss.org/browse/WFCORE-2930 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Fix For: 4.0.0.Beta1 > > > Allow a single socket-binding-group resource as a child of profile, such that resolution of bindings from the subsystems are limited to the s-b-g associated with the profile. > A server-group that uses such a profile cannot reference a socket-binding-group. And a server in that server-group cannot reference an s-b-g to override the one from the server-group/profile. > I'm not sure how the s-b-g resource will work. Perhaps the resource would go away under 'profile' with the bindings direct children of profile. The 'default-interface' attribute then becomes an attribute of profile. Or perhaps there will be an s-b-g resource, but with a fixed name that's the same as the profile. Currently I think the latter. > This will be necessary for resolution of config elements using the upcoming provisioning tool. The tool will not be able to do correct "feature" resolution using the complex rules we currently support. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2830) Split testsuite/shared to distinguish things meant for sharing within the core testsuite from things usable in other projects

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2830?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2830: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha9) > Split testsuite/shared to distinguish things meant for sharing within the core testsuite from things usable in other projects > ----------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2830 > URL: https://issues.jboss.org/browse/WFCORE-2830 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Brian Stansberry > Fix For: 4.0.0.Beta1 > > > The testsuite/shared module includes two conceptually different types of code: > 1) Things that are meant to be usable across different modules in core's own testsuite. > 2) Things that we are willing to support for use in other projects that rely on WildFly Core. > Since the two things are mixed, we are essentially supporting externally things that are not intended for use outside core. And it makes it difficult to evaluate new additions to testsuite/shared, to see whether the addition is really relevant to core and to see whether proposed external use is something we want. > The purpose of WildFly Core is not to be a provider of testsuite utilities. For anything we expose for external use, there should be a substantial code maintenance benefit that comes from sharing it, something beyond avoiding code duplication. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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.Alpha9) > 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)

8 years, 3 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 February 2018