Pragmatic merging of XML

Sometimes it is useful to be able to merge different XML document into one. For example when a tool accepts only one XML configuration file, but different subprojects that use the tool together would each be able to add some information to the XML configuration file. A concrete example would be the web.xml file of a J2EE servlet container: there can only be one such file per WAR-file. What if you have 2 subprojects that you would like to deploy into one WAR-file?
You could merge the files by hand or you could set up an merging functionality to do it automatically for you. With the little framework I present here, you can easily set up your own XML file merging. The framework is available under the EL4J project (http://EL4J.sf.net) as part of the xml merger module. It was contributed by Laurent Bovet (from outside of the EL4J core team), thanks.

Let's look at a simple example:



The following simple code implements this:

public String merge(String original, String patch) {
Configurer c = new PropertyXPathConfigurer("xpath.1=/root/d \n matcher.1=ID");
return new ConfigurableXmlMerge(c).merge(new String[]{original, patch} );
}

You may ask: what does it mean to merge XML documents? I think it is difficult to find a general answer to this question:

• Sometimes the second XML file should be able override tags of the first XML file
  
• What are the branches that should be merged? Just the same XML tags? Or does some attribute need to be equal?
• Sometimes some branches of the XML document may need to be left out

Because of this, the XML merger is set up as a framework. You plug in your own definitions of how matching and mappings are done. There are basic merging semantics implemented in the framework. If you need other rules, you can extend the parts that you are interested in.

Please consult the detailed documentation or the samples of the xml merger in case you would like to know more.

Getting insights in a running Spring application via JMX

During development it is often practical to be able to get more information about what is going on in a running JVM, e.g.

• what Spring configuration was loaded (taking into account all the overridden configuration),
  
• what threads are running and with what properties,
  
• what interceptors are present on what spring beans

The EL4J JMX module allows exactly this. You just add a dependency from your application module to the JMX module and automatically have this and more information available via any web browser.

Here are some screenshots to illustrate this:

First we show the JMX overview page:



Clicking on the fooBean leads to the following view:



Clicking on the Configuration property shows the config values of the bean:




Which corresponds to following spring configuration:


You can also see all the threads that run in the JVM with their attributes:



Additional features:

• Change the log4j logging level for a certain package during runtime
  
• Get the current configuration location of log4j
• See the measurements from the JaMON performance measuring interceptor
• Activate log4j appenders during runtime (e.g. to get more info in case of problems)
  
• See all system properties defined in the JVM (e.g. to get the current CLASSPATH)
  
• Get the order of the configuration files as Spring reads them
  

All this is available with just the addition of a reference to the JMX module. Remark: to make the spring configuration available to JMX, it is required to use a subclass of the normal XMLApplicationContext.