February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-185) Api returns internal server error instead of not found for non-existing path

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-185?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFCORE-185: ------------------------------ Fix Version/s: 3.0.0.Beta3 (was: 3.0.0.Beta2) > Api returns internal server error instead of not found for non-existing path > ---------------------------------------------------------------------------- > > Key: WFCORE-185 > URL: https://issues.jboss.org/browse/WFCORE-185 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Heiko Rupp > Assignee: Brian Stansberry > Labels: rhq > Fix For: 3.0.0.Beta3 > > > When I try to e.g. /subsystem=foo:read-resource the api returns a 500 internal server error. > In http-land, the return code for "not found" is normally 404. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-266) Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-266?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFCORE-266: ------------------------------ Fix Version/s: 3.0.0.Beta3 (was: 3.0.0.Beta2) > Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-266 > URL: https://issues.jboss.org/browse/WFCORE-266 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Beta3 > > > Most of the ParameterValidator implementations that get passed to AttributeDefinition accept params to control whether null and expressions are allowed. These are now redundant, as AttributeDefinition wraps the provided validator with NillableOrExpressionParameterValidator, and it handles that aspect of validation based on the settings of the AD. > So we should deprecate these constructor variants to let people know they aren't needed. Ideally shift the code as well. > CRITICAL: before doing this, make sure the AttributeDefinition variants that support complex types properly wrap any validators that are configured for *element* validation. A quick look shows that ListAttributeDefinition.Builder and MapAttributeDefinition.Builder do. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1059) RestartParentResourceAdd/RemoveHandler should handle capability registration

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1059?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1059: ------------------------------- Fix Version/s: 3.0.0.Beta3 (was: 3.0.0.Beta2) > RestartParentResourceAdd/RemoveHandler should handle capability registration > ---------------------------------------------------------------------------- > > Key: WFCORE-1059 > URL: https://issues.jboss.org/browse/WFCORE-1059 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > Fix For: 3.0.0.Beta3 > > > RestartParentResourceAddHandler and RestartParentResourceRemoveHandler do not extend the respective AbstractAddStepHandler and AbstractRemoveStepHandler base classes, and thus does not handle capability [un]registration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1441) Threads resource classes should make it easy for users to declare capabilities

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1441?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1441: ------------------------------- Fix Version/s: 3.0.0.Beta3 (was: 3.0.0.Beta2) > Threads resource classes should make it easy for users to declare capabilities > ------------------------------------------------------------------------------ > > Key: WFCORE-1441 > URL: https://issues.jboss.org/browse/WFCORE-1441 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Beta3 > > > The classes in the threads modules are now meant for shared use by subsystems in setting up consistent management of thread related resources. An important aspect of that management is the declaration of capabilities, particularly for use in capability-driven model integrity checking. > But the threads module classes do not include any hooks to let the calling code specify the relevant capabilities. > Things probably needed: > 1) Ability to declare the capability that should be registered when a resource is created. > 2) Ability to declare the capability that model reference attributes in a resource refer to. > Perhaps others, but those are the ones that come immediately to mind. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 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 Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1351: ------------------------------- Fix Version/s: 3.0.0.Beta3 (was: 3.0.0.Beta2) > 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.Beta3 > > Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace > > > # 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 (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

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

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1282: ------------------------------- Fix Version/s: 3.0.0.Beta3 (was: 3.0.0.Beta2) > 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.Beta3 > > 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 (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1145: ------------------------------- Fix Version/s: 3.0.0.Beta3 (was: 3.0.0.Beta2) > Review of HostController / Application Server Remoting connections > ------------------------------------------------------------------ > > Key: WFCORE-1145 > URL: https://issues.jboss.org/browse/WFCORE-1145 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 3.0.0.Beta3 > > > Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access. > The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1717) ExtensionXml incorrectly handles duplicate module names

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1717?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1717: ------------------------------- Fix Version/s: 3.0.0.Beta3 (was: 3.0.0.Beta2) > ExtensionXml incorrectly handles duplicate module names > ------------------------------------------------------- > > Key: WFCORE-1717 > URL: https://issues.jboss.org/browse/WFCORE-1717 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.2.0.Final, 3.0.0.Alpha5 > Reporter: Toby Crawley > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta3 > > > Toby Crawley reports: > - adding a duplicate extension under server > extensions causes an > IllegalStateException that occurs when trying to generate the > XMLStreamException > (https://gist.github.com/tobias/59d155afe0c88e268b83cb75734353eb) > The problem happens because before the parser calls the invalidAttributeValue method to throw an exception, it has already consumed the element, preventing invalidAttributeValue working properly. > This should really be a custom exception that more clearly explains the problem, which is that the 'module' attribute value must be unique across the extension elements. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider registration with Elytron

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1802: ------------------------------- Fix Version/s: 3.0.0.Beta3 (was: 3.0.0.Beta2) > Integrate OpenSSL Provider registration with Elytron > ---------------------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta3 > > > We need to remove the following block from SecurityRealmResourceDefinition: - > {code} > static { > //register the Openssl Provider, if possible > //not really sure if this is the best place for it > try { > OpenSSLProvider.register(); > DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider(); > } catch (Throwable t){ > DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider"); > } > } > {code} > Registration will then be possible within the Elytron subsystem configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1649: ------------------------------- Fix Version/s: 3.0.0.Beta3 (was: 3.0.0.Beta2) > RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1649 > URL: https://issues.jboss.org/browse/WFCORE-1649 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Fix For: 3.0.0.Beta3 > > > The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems. > This is a big problem in the following scenarios: > 1) Mixed domain, where legacy slaves do not know about newly introduced classifications. > 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present. > A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But: > -- that doesn't help with problem 2) > -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 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 2017