The current approach is to let the attribute definition handle writing the attribute and this automatically skips writing if the value is the default value. The legacy web subsystem was written before we had this ability. On 26/08/15 14:17, Dominik Pospisil wrote:

The standard behavior is to persist user provided values, regardless of whether they match the default. If the user didn't specify a value and thus relied upon the default, then we don't persist the default. The downside is the xml config contains more data than strictly necessary. The upside is the value often originally comes from the user provided config document, and if we don't write it back when persisting the doc following some unrelated change, we've changed that document unnecessarily. We "share" that document with the end user, so I want to avoid altering it in ways that are not required. This is also why our xml marshaling should always marshal things back in the order they are declared in the xsd, and the standard config docs we ship should also follow that order. We have no way to preserve the original order in which unrelated things were parsed, so if the user doesn't follow xsd order we'll write back in a different order. But at least the order we write in will be predictable. On 8/26/15 8:17 AM, Dominik Pospisil wrote: -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat