{"id":542,"date":"2011-09-22T12:45:00","date_gmt":"2011-09-22T12:45:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/swapping-out-spring-bean-configuration-at-runtime.html"},"modified":"2012-10-21T20:12:55","modified_gmt":"2012-10-21T20:12:55","slug":"swapping-out-spring-bean-configuration","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2011\/09\/swapping-out-spring-bean-configuration.html","title":{"rendered":"Swapping out Spring Bean Configuration at Runtime"},"content":{"rendered":"
Most Java developers these days deal with Spring on a regular basis and there are lots of us out there that have become familiar with its abilities as well as its limitations.<\/p>\n

I recently came across a problem that I hadn\u2019t hit before: introducing the ability to rewire a bean\u2019s internals based on configuration introduced at runtime. This is valuable for simple configuration changes or perhaps swapping out something like a Strategy<\/strong> or Factory<\/strong> class, rather than rebuilding of a complex part of the application context.<\/p>\n

I was able to find some notes about how to do this, but I thought that some might find my notes and code samples useful, especially since I can confirm this technique works on versions of Spring back to 1.2.6. Unfortunately, not all of us are lucky enough to be on the latest and greatest of every library.<\/p>\n

Scope of the Problem<\/span><\/strong><\/p>\n

The approach I\u2019m going to outline is meant primarily to target changes to a single bean, though this code could easily be extended to change multiple beans. It could be invoked through JMX or some other UI exposed to administrators.<\/p>\n

One thing it does not cover is rewiring a singleton all across an application \u2013 this could conceivably be done via some reflection and inspection of the current application context, but is likely to be unsafe in most applications unless they have some way of temporarily shutting down or blocking all processing for a period while the changes are made all over the application.<\/p>\n

The Code<\/span><\/strong><\/p>\n

Here\u2019s the sample code. It will take a list of Strings which contains bean definitions, and wire them into a new temporary Spring context. You\u2019ll see a parent context can be provided, which is useful in case your new bean definitions need to refer to beans already configured in the application.<\/p>\n

public static <T> Map<String, T> extractBeans(Class<T> beanType,\r\n   List<String> contextXmls, ApplicationContext parentContext) throws Exception {\r\n\r\n   List<String> paths = new ArrayList<String>();\r\n   try {\r\n      for (String xml : contextXmls) {\r\n         File file = File.createTempFile(\"spring\", \"xml\");\r\n         \/\/ ... write the file using a utility method\r\n         FileUtils.writeStringToFile(file, xml, \"UTF-8\");\r\n         paths.add(file.getAbsolutePath());\r\n      }\r\n\r\n      String[] pathArray = paths.toArray(new String[0]);\r\n      return buildContextAndGetBeans(beanType, pathArray, parentContext);\r\n\r\n   } finally {\r\n      \/\/ ... clean up temp files immediately if desired\r\n   }\r\n}\r\n\r\nprivate static <T> Map<String, T> buildContextAndGetBeans(Class<T> beanType,\r\n               String[] paths, ApplicationContext parentContext) throws Exception {\r\n\r\n   FileSystemXmlApplicationContext context =\r\n      new FileSystemXmlApplicationContext(paths, false, parentContext) {\r\n         @Override  \/\/ suppress refresh events bubbling to parent context\r\n         public void publishEvent(ApplicationEvent event) { }\r\n      };\r\n\r\n   try {\r\n      \/\/ avoid classloader errors in some environments\r\n      context.setClassLoader(beanType.getClassLoader());\r\n      context.refresh(); \/\/ parse and load context\r\n      Map<String, T> beanMap = context.getBeansOfType(beanType);\r\n\r\n      return beanMap;\r\n   } finally {\r\n      try {\r\n         context.close();\r\n      } catch (Exception e) {\r\n         \/\/ ... log this\r\n      }\r\n   }\r\n} \r\n<\/pre>\n
If you look at buildContextAndGetBeans()<\/strong>, you\u2019ll see it does the bulk of the work by building up a Spring context with the supplied XML bean definition files. It then returns a map of the constructed beans of the type requested.
 
<\/div> <\/div><\/p>\n
Note:<\/strong> Since the temporary Spring context is destroyed, ensure your beans do not have lifecycle methods that cause them to be put into an invalid state when stopped or destroyed.<\/p>\n
Here\u2019s an example of a Spring context that might be used to rewire a component. Imagine we have an e-commerce system that does fraud checks, but various strategies for checking for fraud. We may wish to swap these from our service class without having to stop and reconfigure the application, since we lose business when we do so. Perhaps we are finding a specific abuse of the system that would be better dealt with by changing the strategy used to locate fraudulent orders.<\/p>\n
Here\u2019s a sample XML definition that could be used to rewire our FraudService<\/strong>.<\/p>\n
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n<!DOCTYPE beans PUBLIC \"-\/\/SPRING\/\/DTD BEAN\/\/EN\" \"http:\/\/www.springframework.org\/dtd\/spring-beans.dtd\">\r\n<beans>\r\n   <bean id=\"fraudStrategy\" class=\"com.example.SomeFraudStategory\">\r\n      <!-- example of a bean defined in the parent application context that we can reference -->\r\n      <property name=\"fraudRuleFactory\" ref=\"fraudRuleFactory\"\/>\r\n   <\/bean>\r\n<\/beans>\r\n<\/pre>\n
And here is the code you could use to rewire your bean with a reference to the defined fraudStrategy<\/strong>, assuming you have it in a utility class called SpringUtils<\/strong>:<\/p>\n
public class FraudService implements ApplicationContextAware {\r\n\r\n   private ApplicationContext context;\r\n   \/\/ volatile for thread safety (in Java 1.5 and up only)\r\n   private volatile FraudStrategy fraudStrategy;\r\n\r\n   @Override \/\/ get a handle on the the parent context\r\n   public void setApplicationContext(ApplicationContext context) {\r\n      this.context = context;\r\n   }\r\n\r\n   public void swapFraudStategy(String xmlDefinition) throws Exception {\r\n      List<Sting> definitions = Arrays.asList(xmlDefinition);\r\n      Map<String, FraudStrategy> beans =\r\n         SpringUtils.extractBeans(FraudStrategy.class, definitions, context);\r\n      if (beans.size() != 1) {\r\n         throw new RuntimeException(\"Invalid number of beans: \" + beans .size());\r\n      }\r\n      this.fraudStrategy = beans.values().iterator().next();\r\n   }\r\n\r\n}\r\n<\/pre>\n
And there you have it! This example could be extended a fair bit to meet your needs, but I think it shows the fundamentals of how to create a Spring context on the fly, and use its beans to reconfigure your application without any need for downtime.<\/p>\n
Reference: <\/i><\/strong>Swapping out Spring Bean Configuration at Runtime<\/a> from our JCG partner<\/a>s at the Carfey Software blog<\/a>.<\/p>\n
Related Articles :<\/i><\/strong><\/div>\n