July 2016 - jboss-jira - Jboss List Archives

[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.Alpha4 (was: 3.0.0.Alpha3) > 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.Alpha4 > > > 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1159) Add a runtime operation which shows filesystem usage and availability for known server locations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1159?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1159: ------------------------------------- Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Add a runtime operation which shows filesystem usage and availability for known server locations > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-1159 > URL: https://issues.jboss.org/browse/WFCORE-1159 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Server > Affects Versions: 2.0.2.Final > Reporter: Tristan Tarrant > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Alpha4 > > > For management purposes it would be very useful to report runtime metrics for filesystem usage and availability for known server locations (data, tmp, logs, etc). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 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.Alpha4 (was: 3.0.0.Alpha3) > 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.Alpha4 > > > 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, 10 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.Alpha4 (was: 3.0.0.Alpha3) > 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.Alpha4 > > > 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1167) Upgrade jboss-invocation to include the new blockingCaller flag in InterceptorContext

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1167?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1167: ------------------------------------- Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Upgrade jboss-invocation to include the new blockingCaller flag in InterceptorContext > ------------------------------------------------------------------------------------- > > Key: WFCORE-1167 > URL: https://issues.jboss.org/browse/WFCORE-1167 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Server > Reporter: Farah Juma > Assignee: David Lloyd > Labels: affects_elytron > Fix For: 3.0.0.Alpha4 > > > Upgrade jboss-invocation to a version that includes: > https://github.com/jbossas/jboss-invocation/commit/bae968117dffa6d179ca77... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 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.Alpha4 (was: 3.0.0.Alpha3) > 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.Alpha4 > > > 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1282: ------------------------------------- Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string > --------------------------------------------------------------------------------------- > > Key: WFCORE-1282 > URL: https://issues.jboss.org/browse/WFCORE-1282 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 1.0.2.Final > Environment: Oracle Java > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Alpha4 > > Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log > > > User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7. > Setting as critical as these cipher suites, are considered for strong and widely used in my opinion. > In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all. > Note, that analogous configuration in EAP6 works fine. > Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites(). > Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 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.Alpha4 (was: 3.0.0.Alpha3) > 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.Alpha4 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 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.Alpha4 (was: 3.0.0.Alpha3) > 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.Alpha4 > > > # 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, 10 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: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > 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: Kabir Khan > Fix For: 3.0.0.Alpha4 > > > 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 (v6.4.11#64026)

9 years, 10 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 July 2016