[ https://issues.jboss.org/browse/WFCORE-3807?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3807: ------------------------------------- Description: 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 enhancement prevents this. 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 retain this order following persistence by the server 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. was: 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)