[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.Alpha2
(was: 3.0.0.Alpha1)
> 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.Alpha2
>
>
> 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, 11 months
[JBoss JIRA] (WFCORE-960) CapabilityRegistryResourceDefinition is ignoring CapabilityScope in its reporting
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-960?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-960:
------------------------------------
Fix Version/s: 3.0.0.Alpha2
(was: 3.0.0.Alpha1)
> CapabilityRegistryResourceDefinition is ignoring CapabilityScope in its reporting
> ---------------------------------------------------------------------------------
>
> Key: WFCORE-960
> URL: https://issues.jboss.org/browse/WFCORE-960
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.Beta6
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
> Fix For: 3.0.0.Alpha2
>
>
> The keys for the different registrations in the CapabilityRegistry is their id, which is a combination of their name and their CapabilityScope. CapabilityRegistryResourceDefinition when it reports the registrations is ignoring the scope.
> For WildFly Core 2.0.0.CR1 I'm going to disable registration of CapabilityRegistryResourceDefinition. We don't have specific management client use of this management API yet and it can still use some massaging, so committing ourselves to supporting the current API for many years isn't worth it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-952) Use WildFly Common for null param checks
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-952?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-952:
------------------------------------
Fix Version/s: 3.0.0.Alpha2
(was: 3.0.0.Alpha1)
> Use WildFly Common for null param checks
> ----------------------------------------
>
> Key: WFCORE-952
> URL: https://issues.jboss.org/browse/WFCORE-952
> Project: WildFly Core
> Issue Type: Task
> Reporter: David Lloyd
> Priority: Minor
> Fix For: 3.0.0.Alpha2
>
>
> For each module, do the following:
> * Locate any/all null param check methods in the log msg
> * Replace them with calls to org.wildfly.common.Assert#checkNotNullParam or related method as needed
> * Replace the old null param check method with a comment that reserves the ID and shows that it was previously used for that purpose
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-909) Allow tests to turn on boot-time enforcement of capability resolution in an --admin-only process
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-909?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-909:
------------------------------------
Fix Version/s: 3.0.0.Alpha2
(was: 3.0.0.Alpha1)
> Allow tests to turn on boot-time enforcement of capability resolution in an --admin-only process
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-909
> URL: https://issues.jboss.org/browse/WFCORE-909
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Minor
> Fix For: 3.0.0.Alpha2
>
>
> The OperationContext current will not throw error during boot of an --admin-only process if required capabilities cannot all be resolved, instead simply logging an ERROR. This is to allow the process to boot and give the user an opportunity to fix the problem.
> Test suites often run admin-only processes though to test management of the model without needing to be concerned about runtime services. For these tests, failing on boot if required capabilities are not present may be desired. In particular, it's desirable for WF full's ParseAndMarshalModelsTestCase. So this task is to use a "jboss.unsupported.validate.boot.capabilities" system property to turn on capability resolution enforcement.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-887) "Deprecate" using an expression in model refs to interfaces
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-887:
------------------------------------
Fix Version/s: 3.0.0.Alpha2
(was: 3.0.0.Alpha1)
> "Deprecate" using an expression in model refs to interfaces
> -----------------------------------------------------------
>
> Key: WFCORE-887
> URL: https://issues.jboss.org/browse/WFCORE-887
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Alpha2
>
>
> SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions.
> Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1.
> There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support.
> We should look for other cases like this too, although those changes should be separate JIRAs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 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.Alpha2
(was: 3.0.0.Alpha1)
> 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.Alpha2
>
>
> 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, 11 months
[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.Alpha2
(was: 3.0.0.Alpha1)
> 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.Alpha2
>
>
> 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, 11 months