July 2016 - jboss-jira - Jboss List Archives

[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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1438) Elytron integration with logging subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1438?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1438: ------------------------------------- Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Elytron integration with logging subsystem > ------------------------------------------ > > Key: WFCORE-1438 > URL: https://issues.jboss.org/browse/WFCORE-1438 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha4 > > > This is primarily an investigation task to start with, Logging can use syslog, Syslog access can be protected with TLS, Elytron is providing unified SSL configuration - do we need to bring these together. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

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

1
0
0 / 0

[JBoss JIRA] (WFCORE-1547) Integrate CredentialStore into Core

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1547?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1547: ------------------------------------- Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Integrate CredentialStore into Core > ----------------------------------- > > Key: WFCORE-1547 > URL: https://issues.jboss.org/browse/WFCORE-1547 > Project: WildFly Core > Issue Type: Sub-task > Components: Security > Reporter: Peter Skopek > Assignee: Peter Skopek > Fix For: 3.0.0.Alpha4 > > > Create necessary API for integrating Elytron CredentialStore API into WildFly Core. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2016