[jboss-jira] [JBoss JIRA] (WFCORE-3807) Persist extensions and subsystems in a consistent order
Brian Stansberry created WFCORE-3807:
----------------------------------------
Summary: Persist extensions and subsystems in a consistent order
Key: WFCORE-3807
URL: https://issues.jboss.org/browse/WFCORE-3807
Project: WildFly Core
Issue Type: Enhancement
Components: Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 5.0.0.Alpha6
Always persist extension resources to xml in alphabetical order of the extension module
name.
Always persist subsystem resources to xml in alphabetical order of the subsystem name,
except logging goes first just because it always has. (There has been no technical need
for it to go first since probably before AS 7.0.0.Final.)
The above describes the "conventional" order for the extensions / subsystems in
our standard config files that we've manually applied for many years.
The current persister behavior is to persist extension and subsystems in the order they
were added. This follows the general rule applied everywhere: sibling resources of a type
are persisted in the same order in which they were added. Since most extensions/subsystems
are added at boot based on the parsing of our conventionally ordered standard configs, we
typically persist in our conventional order.
This enhancement is to have the persister force extensions/subsystem persistence in our
conventional order, ignoring the order in which the items were added.
This change has the following pros:
1) If an extension/subsystem is added after initial boot (e.g. via CLI) the placement of
that added subsystem will now be in a more intuitive spot in the same order as the
conventionally ordered others, versus now where it comes last.
2) The galleon provisioning tool when it provisions a server basically does a bunch of 1),
with the adds happening based on dependency analysis of the features. This results in an
ordering that can seem quite unintuitive. This enhancement prevents this.
3) With the current behavior if a galleon feature pack is upgraded, and the feature-spec
reports new dependency information that was previously missing (e.g. proper
capability/requirement wiring between subsystems was added whereas before only
invisible-in-the-model service dependencies were used) then when galleon re-provisions the
server the order of extensions/subsystems might mysteriously change.
This change has the following cons:
1) If users for some reason had deliberately organized their xml in a different order from
our convention, the ability to do this would be lost. (We could add a system property hook
to disable this enhancement, but it would need to be clear that it's not something the
galleon tool itself supports. So probably not a great idea.)
2) The ordering that galleon will create without this enhancement does provide some value
to the user since it gives a rough sense of dependency ordering. It's pretty rough
though, as there can be numerous items A, B, C that come before other items X, Y, Z where
there is no dependency relationship involved.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)