[jboss-jira] [JBoss JIRA] (WFCORE-3524) Attempt to initialize the latest Extension parser if that has been registered are suppliers

[Brian Stansberry (JIRA)]

     [ https://issues.jboss.org/browse/WFCORE-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3524:
-------------------------------------
    Description: 
The ExtensionParsingContext.setSubsystemXmlMapping(String subsystemName, String namespaceUri, Supplier<XMLElementReader<List<ModelNode>>> supplier) method may save memory space by deferring construction of the parser, but it also may mean that the management model classloading and definition initialization work that often is done by the parser is deferred until parsing begins. And parsing is a single-threaded part of boot, so deferring this work out of the concurrent extension initialization work until parsing slows down boot.

I'd been asking people to use the non-supplier ExtensionParsingContext.setSubsystemXmlMapping variant for the latest parser, but that's unintuitive and requires further unintuitive work every time a new parser is added.

To limit the need for that, instead the ExtensionRegistry, if it sees that only suppliers have been registered, will attempt to construct the "latest" parser (by calling its supplier). It will determine the "latest" supplier by lexicographic comparison of the registered namespaces.

See the discussion on https://github.com/wildfly/wildfly-core/pull/3035

  was:
The ExtensionParsingContext.setSubsystemXmlMapping(String subsystemName, String namespaceUri, Supplier<XMLElementReader<List<ModelNode>>> supplier) method may save memory space by deferring construction of the parser, but it also may mean that the management model classloading and definition initialization work that often is done by the parser is deferred until parsing begins. And parsing is a single-threaded part of boot, so deferring this work out of the concurrent extension initialization work until parsing slows down boot.

I'd been asking people to use the non-supplier ExtensionParsingContext.setSubsystemXmlMapping variant for the latest parser, but that's unintuitive and requires further unintuitive work every time a new parser is added.

To limit the need for that, instead the ExtensionRegistry, if it sees that only suppliers have been registered, will attempt to construct the "latest" parser (by calling its supplier). It will determine the "latest" supplier by lexicographic comparison of the registered namespaces.



> Attempt to initialize the latest Extension parser if that has been registered are suppliers
> -------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3524
>                 URL: https://issues.jboss.org/browse/WFCORE-3524
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> The ExtensionParsingContext.setSubsystemXmlMapping(String subsystemName, String namespaceUri, Supplier<XMLElementReader<List<ModelNode>>> supplier) method may save memory space by deferring construction of the parser, but it also may mean that the management model classloading and definition initialization work that often is done by the parser is deferred until parsing begins. And parsing is a single-threaded part of boot, so deferring this work out of the concurrent extension initialization work until parsing slows down boot.
> I'd been asking people to use the non-supplier ExtensionParsingContext.setSubsystemXmlMapping variant for the latest parser, but that's unintuitive and requires further unintuitive work every time a new parser is added.
> To limit the need for that, instead the ExtensionRegistry, if it sees that only suppliers have been registered, will attempt to construct the "latest" parser (by calling its supplier). It will determine the "latest" supplier by lexicographic comparison of the registered namespaces.
> See the discussion on https://github.com/wildfly/wildfly-core/pull/3035



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)