wildfly-server-migration rewrites self-closing XML tags (<tag/> → <tag></tag>) – is there a way to preserve the original format?

27 views
Skip to first unread message

Sof Ham

unread,
Feb 9, 2026, 9:27:48 AMFeb 9
to WildFly

Hello,

I recently tested the wildfly-server-migration tool and I found it really useful and impressive.

However, I noticed one side effect during the migration of the configuration files:
self-closing XML tags such as:

<sometag/>

are systematically rewritten as:

<sometag></sometag>

From a functional point of view this is equivalent, but it creates a lot of unnecessary differences in configuration files, which makes reviews and comparisons more difficult.

Is there any option, configuration, or recommended approach to preserve self-closing XML tags during the migration?

Or is this behavior inherent to the XML processing library used by the tool?

Thank you in advance for your feedback.

Sofiane

Brian Stansberry

unread,
Feb 9, 2026, 9:34:45 AMFeb 9
to WildFly
If you take a server running your config with self-closing tags and use the WildFly CLI to change it, do the tags change?

Say, for example, add and remove a meaningless system-property resource:

/system-property=foo:add(value=bar)
/system-property=foo:remove

The server will re-write the file after any change.

If the tags change the change is an inherent property of how the server persists things and is not configurable and probably isn't something we'd change. (The persistence logic has no idea whether or not self-closing tags were used, so changing things would then mean people who don't use them would see their config change.)

If that procedure doesn't result the same changes, then we are talking about something done by the migration tool and I'll defer to the experts on it to comment.

Eduardo Martins

unread,
Feb 9, 2026, 9:55:59 AMFeb 9
to Sof Ham, WildFly
Hi Sofiane, the tool may manipulate the config XML with the server off and running. If the change is while running it’s what Brian described before, nothing the tool can do, this the server persisting the config, but if it’s while the server is offline then maybe the tool’s XML writer can be configured to avoid that. Can you please show me the concrete XML change?
 
—E

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wildfly/4bb426be-9e19-4ad2-853a-32e89fb6d548n%40googlegroups.com.

Sof Ham

unread,
Feb 9, 2026, 12:57:45 PMFeb 9
to Eduardo Martins, WildFly
Dear Eduardo ,

Thanks a lot for answering. The server I getting information is old (Wildfly 34) and the new one is Wildfly 36. The old server was runing when I launched the command. I'll try when it's off and let you know.

Best regards,
Sofiane
--

Cordialement, Best Regards, Mit freundlichen Grüßen,

Sofiane HAMMAMI

Eduardo Martins

unread,
Feb 11, 2026, 5:14:23 PMFeb 11
to Sof Ham, WildFly
Hi, sorry I was not clear enough, migration should always be done with servers off. I meant that it is the migration tool that first may change the configuration still offline (e.g. to remove something that prevents the configuration to boot in the new server), and then boots the possibly already modified configuration in the new server, and then use the management interface to further modify it. 

Sof Ham

unread,
Feb 11, 2026, 5:16:07 PMFeb 11
to Eduardo Martins, WildFly
Dear Eduardo,

I have made a test today while the server is off. It didn't change the tags. That's awesome!

Thank you 

Cordialement, Best Regards, Mit freundlichen Grüßen,

Sofiane HAMMAMI

Reply all
Reply to author
Forward
0 new messages