Announcement Announcement Module
No announcement yet.
Dealing with XML config maintenance Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Dealing with XML config maintenance

    Are there any recommendations for validating your various Spring XMLs for code changes such as renaming a class or removing a setter from a class? The concern is mostly related to the production XML, but for example WRT a name change, that name may be in multiple Spring files. I can evaluate the test XML easy enough by running the test suite and fixing any failures/errors, but it would be nice not to have to hit RuntimeExceptions to debug the production XML.

  • #2
    Not runtime, of course, but the Spring IDE eclipse plug-in does validation.


    • #3
      I too was annoyed that I had to wait until the runtime to fix bad bean defs (with jboss, the exception trace is so long and I found it difficult to get the original exception).

      So I wrote a simple ant target to validate my spring files:

      <target name="validate-spring">
      <java fork="true" failonerror="true" classname="SpringFilesValidation">
      <arg value="applicationContext-XXX.xml"/>
      <arg value="applicationContext-Jmx.xml"/>
      <arg value="test/applicationContext-for-validation.xml"/>
      <pathelement path="${classes.dir}"/>
      <path refid="path.classpath"/>

      public class SpringFilesValidation {

      public static void main(String[] files) {
      try {
      System.out.println(" Validating springs files...");
      // Disable the logging (was too verbose and not necessary)
      System.setProperty("org.apache.commons.logging.Log ", "org.apache.commons.logging.impl.NoOpLog");
      new ClassPathXmlApplicationContext(files);
      System.out.println(" *** Spring files are OK *** ");
      } catch (BeansException e) {
      System.err.println("############## ERROR IN APPLICATION CONTEXT ############");

      It will at least validate the basic definitions and associations. But I had to override certain beans (via applicationContext-for-validation.xml) since some of them require a running app server for validation (such as Jms and JNDI lookup).



      • #4
        The org.springframework.test package is handy for integration tests that are still outside the server. So no phone book stack traces.