May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1130) Add support for an ObjectMapAttributeDefinition i.e. the value type is an ObjectTypeAttributeDefinition

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1130?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1130: ------------------------------------- Fix Version/s: 3.0.0.Alpha2 (was: 3.0.0.Alpha1) > Add support for an ObjectMapAttributeDefinition i.e. the value type is an ObjectTypeAttributeDefinition > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1130 > URL: https://issues.jboss.org/browse/WFCORE-1130 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Tomaz Cerar > Labels: affects_elytron > Fix For: 3.0.0.Alpha2 > > > Within Elytron we have some configuration that we need to model by having a 'credential-name' as a key, this needs to be associated with a value represented by four different strings. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1128) Improve the subsystem test schema test coverage

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1128?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1128: ------------------------------------- Fix Version/s: 3.0.0.Alpha2 (was: 3.0.0.Alpha1) > Improve the subsystem test schema test coverage > ----------------------------------------------- > > Key: WFCORE-1128 > URL: https://issues.jboss.org/browse/WFCORE-1128 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.1.Final > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 3.0.0.Alpha2 > > > Currently the way to enable the AbstractSubsystemBaseTest testSchema() and testSchemaOfSubsystemTemplates() tests is to override getSubsystemXsdPath() and getSubsystemTemplatePaths(). > Rather than making it explicit to turn on, it should be explicit to turn off. > Also the current way of doing this uses Assume.assumeTrue() to check if a test has provided a schema file, which provides a lot of ignored test noise in the test output. If the xsd should not be tested, methods should instead override testSchema() or testSchemaOfSubsystemTemplates() and provide an empty implementation with a comment saying why it is not important. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1116) Review initial user creation process.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1116?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1116: ------------------------------------- Fix Version/s: 3.0.0.Alpha2 (was: 3.0.0.Alpha1) > Review initial user creation process. > ------------------------------------- > > Key: WFCORE-1116 > URL: https://issues.jboss.org/browse/WFCORE-1116 > Project: WildFly Core > Issue Type: Enhancement > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha2 > > > We started off with a very simple add user utility where the purpose was just to get the first management user added so users could remotely administer the server, this tool has grown and grown so now it covers management users and application users. we also have additional questions in relation to groups that are not obvious to users what they need to add. > This task is to look into providing something that in it's simplest form just focusses on the first management user. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1400) Update management interfaces to obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1400?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1400: ------------------------------------- Fix Version/s: 3.0.0.Alpha2 (was: 3.0.0.Alpha1) > Update management interfaces to obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability > ----------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1400 > URL: https://issues.jboss.org/browse/WFCORE-1400 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1351: ------------------------------------- Fix Version/s: 3.0.0.Alpha2 (was: 3.0.0.Alpha1) > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1351 > URL: https://issues.jboss.org/browse/WFCORE-1351 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Critical > Fix For: 3.0.0.Alpha2 > > > # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1349) Upgrate JBoss Marshalling to >= 1.4.11.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1349?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1349: ------------------------------------- Fix Version/s: 3.0.0.Alpha2 (was: 3.0.0.Alpha1) > Upgrate JBoss Marshalling to >= 1.4.11.Final > -------------------------------------------- > > Key: WFCORE-1349 > URL: https://issues.jboss.org/browse/WFCORE-1349 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: David Lloyd > Fix For: 3.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1429) Add property to skip LogManager check at startup

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1429?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1429: ------------------------------------- Fix Version/s: 3.0.0.Alpha2 (was: 3.0.0.Alpha1) > Add property to skip LogManager check at startup > ------------------------------------------------ > > Key: WFCORE-1429 > URL: https://issues.jboss.org/browse/WFCORE-1429 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: Dominique Broeglin > Assignee: James Perkins > Priority: Minor > Fix For: 3.0.0.Alpha2 > > > At startup, Wildfly checks that the default log manager (as returned by {{java.util.logging.LogManager.getLogManager()}} ) is {{org.jboss.logmanager.LogManager}}: > https://github.com/wildfly/wildfly-core/blob/master/logging/src/main/java... > This breaks some cases where the LogManager is wrapped because of the needs of that particular JVM like in OSv ( https://github.com/cloudius-systems/osv/blob/master/java/runjava/src/main... ). > As suggested on the mailing list, I would like to propose adding a property to bypass that check. Something along the lines of "jboss.logging.logManagerCheck = false/true" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1237) Remove @Deprecated from ExtensionContext.isRegisterTransformers()

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1237?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1237: ------------------------------------- Fix Version/s: 3.0.0.Alpha2 (was: 3.0.0.Alpha1) > Remove @Deprecated from ExtensionContext.isRegisterTransformers() > ----------------------------------------------------------------- > > Key: WFCORE-1237 > URL: https://issues.jboss.org/browse/WFCORE-1237 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 3.0.0.Alpha2 > > > Even if we change how transformers are done, this method could probably be retained for a bit. It's annoying to have a method every extension must invoke giving a deprecation warning for years for something maybe we'll change. > And SubsystemRegistration.registerModelTransformers isn't deprecated and its the method far more likely to be broken by any change. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1197) Enhance missing capability logging during subsystem testing

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1197?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1197: ------------------------------------- Fix Version/s: 3.0.0.Alpha2 (was: 3.0.0.Alpha1) > Enhance missing capability logging during subsystem testing > ----------------------------------------------------------- > > Key: WFCORE-1197 > URL: https://issues.jboss.org/browse/WFCORE-1197 > Project: WildFly Core > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 2.0.4.Final > Reporter: Darran Lofthouse > Assignee: Tomaz Cerar > Labels: affects_elytron > Fix For: 3.0.0.Alpha2 > > > Making changes to the Undertow subsystem I was presented with the following failure: - > {noformat} > <testcase name="testRuntime" classname="org.wildfly.extension.undertow.UndertowSubsystemTestCase" time="1.611"> > <error type="java.lang.NullPointerException:">java.lang.NullPointerException: null > at org.wildfly.extension.undertow.UndertowSubsystemTestCase.testRuntime(UndertowSubsystemTestCase.java:118) > {noformat} > It was only after enabling other logging I found the real cause: - > {noformat} > ec 08, 2015 6:19:22 PM org.jboss.as.controller.OperationContextImpl validateCapabilities > ERROR: WFLYCTL0362: Capabilities required by resource '/subsystem=undertow/application-security-domain=other' are not available: > org.wildfly.security.http-server-mechanism-factory.elytron-factory; There are no known registration points which can provide this capability. > {noformat} > The NullPointerException above is because it is detected the booting failed but the error was never made available. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1220) Try closing the channel if java.lang.Error prevents sending error responses to the client

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1220?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1220: ------------------------------------- Fix Version/s: 3.0.0.Alpha2 (was: 3.0.0.Alpha1) > Try closing the channel if java.lang.Error prevents sending error responses to the client > ----------------------------------------------------------------------------------------- > > Key: WFCORE-1220 > URL: https://issues.jboss.org/browse/WFCORE-1220 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 3.0.0.Alpha2 > > > Beyond the basic work on WFCORE-1134, look into further reaction when Errors occur and the server or HC cannot even send an error response to the caller. If we get to this point, the task has already failed to handle a problem and now we can't notify the remote side either. Most likely this is an OOME situation, although any Error here means a major issue. > Options: > 1) Try and close the channel to disconnect this process from the remote end so it doesn't disrupt the remote end. If this is an intra-HC or HC-server connection a successful close will remove this process from normal domain control. If this is a server the HC still has some control over the server via the ProcessController, e.g. to handle a 'kill' or 'destroy' management op. If this is a slave HC, the slave is disconnected from the domain. Either a server or a slave HC may try to reconnect, although it's likely better if that fails and the user just restarts the process. > If the remote side is an end user client (e.g. CLI) then a successful close will be noticed by the client. The user can reconnect or take action to terminate this process. > 2) Commit suicide via SystemExiter.exit. But I'm not certain complete termination of the process is how we want to deal with problems with management requests. Probably some sort of configurable policy would be better. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 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 May 2016