July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1154) Deprecate permgen attributes in host and server config level jvm settings

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1154?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1154: ------------------------------------- Fix Version/s: 3.0.0.Alpha5 (was: 3.0.0.Alpha4) > Deprecate permgen attributes in host and server config level jvm settings > ------------------------------------------------------------------------- > > Key: WFCORE-1154 > URL: https://issues.jboss.org/browse/WFCORE-1154 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Alpha5 > > > The permgen size attributes no longer do anything in a core 2.0 or later server, as we require JDK 8 and our code ignores these if JDK 8 or later is running. So we should deprecate the config elements and log a message if they are used, and add deprecation text in the xsd. > I considered only deprecating these attributes if they appear in the host=* tree, and not doing the ones for domain-wide resources, since those could be used for legacy slaves running JDK < 8. But I think the distinction isn't worth the effort. First, these things are deprecated in all cases in the sense that they may go away in some future release. And second, all that happens is an INFO message is logged, and the chances that message may help some JDK 8 user offsets the chance that a JDK < 8 user would be annoyed by some spurious INFO logging. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

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

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1145: ------------------------------------- Fix Version/s: 3.0.0.Alpha5 (was: 3.0.0.Alpha4) > 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.Alpha5 > > > 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 (v6.4.11#64026)

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

1
0
0 / 0

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

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1059?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1059: ------------------------------------- Fix Version/s: 3.0.0.Alpha5 (was: 3.0.0.Alpha4) > RestartParentResourceAdd/RemoveHandler should handle capability registration > ---------------------------------------------------------------------------- > > Key: WFCORE-1059 > URL: https://issues.jboss.org/browse/WFCORE-1059 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > Fix For: 3.0.0.Alpha5 > > > 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 (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1053) Model compatibility tests

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1053?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1053: ------------------------------------- Fix Version/s: 3.0.0.Alpha5 (was: 3.0.0.Alpha4) > Model compatibility tests > ------------------------- > > Key: WFCORE-1053 > URL: https://issues.jboss.org/browse/WFCORE-1053 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 3.0.0.Alpha5 > > > Once the infrastructure is in place, we will need to test all subsystems here and in WildFly. > The basic idea is some variety of CompareModelVersionsUtil and compare the current resource registrations against a stored snapshot of the resource registrations -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1054) Better subsystem test coverage

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1054?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1054: ------------------------------------- Fix Version/s: 3.0.0.Alpha5 (was: 3.0.0.Alpha4) > Better subsystem test coverage > ------------------------------ > > Key: WFCORE-1054 > URL: https://issues.jboss.org/browse/WFCORE-1054 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 3.0.0.Alpha5 > > > The subsystem and core-model tests should be expanded to test FULL models. In many(?) cases these tests do not use a full xml. We should generate a full xml file for testing, possibly by using the schema. Or by inspecting the resource registrations a bit similar to the ExpressionSupportTestCase. > We might need something to deal with the case where e.g. a parent expects only one of two children to be set (i.e. there is a choice) and not both. In those cases it would be good to be able to test all possible permutations. This testing should be at least the parsing and marshalling of the main model. It is uncertain whether it will be possible to do do transformers, although perhaps we could do something like the DomainAdjusters from the mixed domain tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1006) Upgrade to PicketBox 5

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1006?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1006: ------------------------------------- Fix Version/s: 3.0.0.Alpha5 (was: 3.0.0.Alpha4) > Upgrade to PicketBox 5 > ---------------------- > > Key: WFCORE-1006 > URL: https://issues.jboss.org/browse/WFCORE-1006 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Stefan Guilhen > Fix For: 3.0.0.Alpha5 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

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

9 years, 9 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.Alpha5 (was: 3.0.0.Alpha4) > 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.Alpha5 > > > # 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, 9 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