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