# config managing JBoss II: The XMLening **URL:** \ **Category:** Ansible Project\ **Created:** [June 23, 2016, 8:44am UTC](https://forum.ansible.com/t/config-managing-jboss-ii-the-xmlening/21841 "2016-06-23T08:44:09Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Dick\_Davies](https://avatars.discourse-cdn.com/v4/letter/d/b9e5f3/32.png) [@Dick\_Davies](https://forum.ansible.com/u/Dick_Davies)\ **Post date:** [June 23, 2016, 8:44am UTC](https://forum.ansible.com/t/config-managing-jboss-ii-the-xmlening/21841/1 "2016-06-23T08:44:09Z")
I ased a few weeks ago about taming JBoss (AS7.1 / EAP6) with Ansible (1.9.x) - started in on it this week and I'm hitting the hurdles I'd predicted then (bit of a war story incoming, feel free to skip to the 'Help!' section): Fun facts: \* there are 0 playbooks out there that manage JBoss in an idempotent way \* JBoss is actively CM hostile (like, \_Jenkins\_ hostile) the gist is JBoss writes its domain.xml whenever it feels like it, so it's not safe to template that directly. Most guides recommend using the jboss-cli tool to a) ensure uncorrupted config and b) avoid some restarts. I can do that sort of thing with a command: but I'd need to run a 'getter' command: first to check the state of the config, which is a bit ugly if you're doing lots of changes. There's a tool called 'jcliff' ( [https://github.com/bserdar/jcliff](https://github.com/bserdar/jcliff)) which tries to solve this problem, and has the advantage of being idempotent. Downside is it's docs are pretty dense, it only supports a subset of the CLIs DMR data structures , and domain mode support is a hack. I've spent an hour trying to figure out how to get it to change a log level and most of that was debugging jcliff rather than JBoss. At this point its looking uglier than just '2 commands per config change' plan above. The ansible-xml library looks like it would do a decent job of managing config files but as I said JBoss would need to be shut down. I want this to be safe to run without downtime if no deltas are needed. Finally, there are a load of JBoss nerd^W experts here so any config snippets are likely to be written by them rather than me, so deltas that support the JBoss DMR are a bonus. Help! At this point I think I'm going to have to go with plan A - run a jboss-cli getter, then a jboss-cli setter if needed Does anyone know of a module that wraps commands like this? I've never written an Ansible module before but this seems like it might be a plan. If anyone has ever tamed JBoss and wants to tell me the secret, that'd be cool too 🙂 Thanks for listening. ---
**Author:** ![Jeroen\_Hoekx](https://avatars.discourse-cdn.com/v4/letter/j/ba9def/32.png) [@Jeroen\_Hoekx](https://forum.ansible.com/u/Jeroen_Hoekx)\ **Post date:** [June 23, 2016, 10:33am UTC](https://forum.ansible.com/t/config-managing-jboss-ii-the-xmlening/21841/2 "2016-06-23T10:33:51Z")
Hi, > Fun facts: > > \* there are 0 playbooks out there that manage JBoss in an idempotent way > \* JBoss is actively CM hostile (like, \_Jenkins\_ hostile) > > The ansible-xml library looks like it would do a decent job of > managing config files but as I said JBoss would need to be shut down. > I want this to be safe to run without downtime if no deltas are > needed. We've been managing JBoss with Ansible for about 3 years now in an idempotent way. I agree that JBoss does not make it easy for a configuration management system like Ansible. This is our approach: - we store the configuration xml (standalone.xml in our case) as an artifact in our build process - during deployment we template the xml jinja template in a different location - we compare it to the current xml config - when there is a diff, we print it and stop JBoss, move the new config in place and restart JBoss - then we deploy the new artifacts using the jboss module There are two caveats: - It is important to not deploy through the cli, as this changes the xml. Filesystem deployments avoid that. - Keep the xml namespaces up to date with your JBoss version, as JBoss automatically converts old xmlns declarations to new ones. It is rather different than your proposed approach, but perhaps this pragmatic way of configuring JBoss avoids the work you would have to put in a module. Greetings, Jeroen ---
**Author:** ![Dick\_Davies](https://avatars.discourse-cdn.com/v4/letter/d/b9e5f3/32.png) [@Dick\_Davies](https://forum.ansible.com/u/Dick_Davies)\ **Post date:** [June 23, 2016, 10:40am UTC](https://forum.ansible.com/t/config-managing-jboss-ii-the-xmlening/21841/3 "2016-06-23T10:40:40Z")
Thanks Jeroen glad that works at least - it'd be my fallback position if this driving jboss-cli gets ugly. Do you get many false positives on the diffs, or is JBoss OK at keeping the DOM structure more or less constant (last time I tried something like that was early tomcat releases, and it seemed to shuffle XML as much as it could when it synced back)? ---
**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\ **Post date:** [June 23, 2016, 2:42pm UTC](https://forum.ansible.com/t/config-managing-jboss-ii-the-xmlening/21841/4 "2016-06-23T14:42:08Z")
The template module does this by default (the diff if ansible is called with --diff), add a notify handler for the restart and you have all the steps. ---
**Author:** ![Josh\_Smift1](https://avatars.discourse-cdn.com/v4/letter/j/bcef8e/32.png) [@Josh\_Smift1](https://forum.ansible.com/u/Josh_Smift1)\ **Post date:** [June 23, 2016, 2:53pm UTC](https://forum.ansible.com/t/config-managing-jboss-ii-the-xmlening/21841/5 "2016-06-23T14:53:53Z")
> The template module does this by default (the diff if ansible is > called with --diff), add a notify handler for the restart and you have > all the steps. Right, but with JBoss, the destination file may have been changed since Ansible pushed it out (because JBoss likes to rewrite its XML files). So in that case, you can stash a copy of the file somewhere \*else\*, have the template module push to there, and notify a handler that then pushes the template to the real location and does the restart.                                       -Josh (jbs@care.com) (apologies for the automatic corporate disclaimer that follows) This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system. ---
**Author:** ![Jeroen\_Hoekx](https://avatars.discourse-cdn.com/v4/letter/j/ba9def/32.png) [@Jeroen\_Hoekx](https://forum.ansible.com/u/Jeroen_Hoekx)\ **Post date:** [June 23, 2016, 5:17pm UTC](https://forum.ansible.com/t/config-managing-jboss-ii-the-xmlening/21841/6 "2016-06-23T17:17:44Z")
Hi, > Do you get many false positives on the diffs, or is JBoss OK at > keeping the DOM structure more or less constant (last time I tried something > like that was early tomcat releases, and it seemed to shuffle XML as much as > it could when it synced back)? The DOM stays quite OK. I listed the only two conditions we've encountered in my mail: \* JBoss updates the subsystem xml namespaces when updating, and rewrites the xml config with the new namespaces. You have to update your configuration to follow these changes. \* Deployments with the JBoss CLI add content to the XML file. This is to be avoided. Greetings, Jeroen