While I would love to provide some enlightment to the reader on this topic, it is simply off topic, so I will just show the content of the style sheet I designed to add a server entry to the host.xml: Especially, if you are coming from a regular RHEL administrator background and never had the basis of it. Sadly (and no one will get an argument from me about that) XSLT instructions is not that easy to understand. The first step here consists of writing an appropriate style sheet.

This example will focus on editing this file, within a script, to add server definitions to it. One key configuration file of this feature is the 'domain/configuration/host.xml' file, which describes how many instance should be run on one host. Since the release of JBoss AS 7 (which is used as a base for JBoss EAP 6), the JEE application server offers a new mode of operation, called domain mode, which allows you to run several instances of the server, even across several systems, as a whole. Let's look at a concrete example to see how one can leverage this.Īdding a server to a server group in JBoss AS host definition Editing with the XML structure using XSLT As the command allows one to pass parameters for the style sheet, it is also quite a handy tool for script usage. This allows you to process an XML files using a XSLT style sheet, enabling one to easily modify its structure while ensuring the file remains valid. Fortunately, another useful command from the 'libxml' package comes to our rescue for this purpose: xsltproc. As stated previously, adding or removing child elements, or tweaking attributes, are simply not easy to achieve with the regular script tricks. If 'xmlwf' is helpful, the hard point in handling XML files certainly does not rely in their validation, but their editing. While quite old, and not perfect (for instance, an invalid file does not result into the command returning a non zero status), this command is still quite handy to me on a daily basis. I quite recently discovered the command 'xmlwf', coming with the 'expat' package, which allow to perform such validation operation: For this reason, it's pretty important, when editing such file within a script, to validate before and after editing that the structure is proper XML. However, the bad thing is with it is that it's quite easy to break such structured format. One of the good things with XML is that it's a structured format. In this section, we will therefore introduce a couple of tools, available on any good Linux distribution (or easy to install), that will provide better support to handle XML content. Bottom line is: those awesome and standard tools are simply not the best ones for the job. For instance, if a 'sed' statement assume that the XML attribute to edit is on the same line as the node tag, it will break if the file spacing is modified, while the XML file will remains valid.Īlong with this, it is also extremely difficult to rely on such editing tools to perform rather crucial XML changes such as adding child node or removing a complete block. Indeed, those tools, on the contrary of the XML standard, assume that spacing within the files is structured and relevant. While one can use 'sed' or 'awk' to process XML files, it is always a tricky job. While the XML format has some definitive qualities, it is not the easiest format to parse, and this often causes issues when integrating product inside an RPM or designing an automated installation procedure.Īs I've been working on such automation for most of my career, I've picked up a bunch of nifty tricks and also designed some useful practices that I wanted to share on this blog.

This is even more true when it comes to the Red Hat middleware portfolio, the JBoss projects having always been keen on using this format for configuration files - on top of the ones specified by JEE such as the famous (or infamous ?) web.xml.

Countless products uses XML files, whether it is for data persistence, serialization or mere configuration.

Linux xml editor