Conditional creation of bean in spring or conditional import/inclusion of spring context

We ran into a situation where our application needed to create a bean only if we are running it for a particular vendor and a different bean for other vendors. These beans were for classes which didn't have control and there were no common interface to come up with factory like pattern. Also we could not leave both beans created together. In short we were left with choices to either create two different wars with specific spring context file, or put those two beans into separate context files and include them conditionally in base context file based on some configuration parameter at run time .

It took us a while to figure out but there seems to be multiple ways to achieve this. We are still stuck with spring 3.2 so won't discuss anything available in newer versions like this. Following are options we tried and worked for us, however we chose to go with "Using profiles" approach

1. Using profiles 
2. Using property placeholder
3. By extending existing XSDs to have a "if else" kind of tags

Using profiles

Spring (3.2 onward) allows us to specify sub-sections in context file which are activated (or even present in final context files after resolving all imports) only if that profile is active. 

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="
      http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans-3.2.xsd
      http://www.springframework.org/schema/context
      http://www.springframework.org/schema/context/spring-context-3.2.xsd" >
 

       <!-- here goes common beans -->

   <beans profile="Prof_1">
         <import resource="./first-config.xml" />
  </beans>
  <beans profile="Prof_2">
         <import resource="./second-config.xml" />
  </beans>
</beans>

One can activate multiple profile at same time or choose not to activate any. To activate there are multiple ways but to programtaically do this we need to add a initializer in web.xml

<context-param>
<param-name>contextInitializerClasses</param-name>
<param-value>com.test.MyCustomInitializer</param-value>
</context-param>

MyCustomInitializer looks like following

public class MyCustomInitializer implements ApplicationContextInitializer<ConfigurableApplicationContext> {

@Override
public void initialize(ConfigurableApplicationContext applicationContext) {
try {
                        String activeProf;
                        // some logic to either read file/env variable/setting to determine which profile to activate
applicationContext.getEnvironment().setActiveProfiles( activeProf );
} catch (IOException e) {
e.printStackTrace();
}
}

}

Using property placeholder

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:context="http://www.springframework.org/schema/context"

xsi:schemaLocation="

      http://www.springframework.org/schema/beans 

      http://www.springframework.org/schema/beans/spring-beans-3.2.xsd

      http://www.springframework.org/schema/context 

      http://www.springframework.org/schema/context/spring-context-3.2.xsd" >

    

       <!-- here goes common beans -->

  <import resource="./${identifier}-config.xml" />

</beans>

PlaceHolderConfigurer bean can't be used in the context itself as imports are resolved even before any bean gets created. So we again need to register a listener as we did in previous method and replace following line in initializer class (assume that we have property file from where we are picking "identifier" as either "first" or "second")

applicationContext.getEnvironment().getPropertySources().addFirst( new ResourcePropertySource( new ClassPathResource( "environment.properties" ) ) );

By extending existing XSDs to have a "if else" kind of tags

This allows us to have following kind of syntax in context 

<condbean:cond test="${developmentmode}">

  <bean id="industryDAO" class="robertmaldon.app.dao.HibernateIndustryDAO">

      <property name="sessionFactory" ref="sessionFactory"/>

  </bean>

</condbean:cond>

More details at http://robertmaldon.blogspot.com/2007/04/conditionally-defining-spring-beans.html

Consuming same WSDL from different end points/hosts without reloading

We have a device which can be controlled using web service described by a WSDL. We have hundreds of similar device to be controlled from a software. All devices exposes same WSDL but only hostname is changed. While using Java's wsimport generated client API, we need to pass WSDL location and all subsquent call are done to the location defined by this WSDL. As we need to manage multiple devices, we need to initiate API with different WSDL location. This involves loading, parsing of WSDL for each device even its same for all. To avoid this, we can use approach described in following article

https://issues.jboss.org/browse/JBWS-2379

We statically create service from a WSDL and than override host info for each call for aparticular host as follows
Service service = (Service) Service.create(wsdlURL, serviceQName);

port = service.getPort(MyServiceApi.class);

BindingProvider bp = (BindingProvider) port;
bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,"http://10.95.14.134/soap");

here the value should be same as defined in the location for port in service

null argument method ambiguity resolution

This is a summary of what I understood from a quite interesting discussion[1]. Think of a case as follows

public class MyClass {
    MyClass(CharSequence charSeq) {
        System.out.println("CharSequence");
    }
    MyClass(String s) {
        System.out.println("String");
    }  
    public static void main(String[] args) {
        new MyClass(null); // prints "String"
        new MyClass(""); // prints "String"
        new MyClass((CharSequence) null); // prints "CharSequence"
        new MyClass((CharSequence) "");   // prints "CharSequence"
    }
}

Now to understand why its working in this way, we need to get into policy defined in java (http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.12.2.5) for compile time method resolution.

Java uses two pass approach, in first pass find all applicable methods, if more than one such method, in second pass use most specific method if can be determined else ambiguity issue.

15.12.2.5 Choosing the Most Specific Method

If more than one member method is both accessible and applicable to a method invocation, it is necessary to choose one to provide the descriptor for the run-time method dispatch. The Java programming language uses the rule that the most specific method is chosen.

The informal intuition is that one method is more specific than another if any invocation handled by the first method could be passed on to the other one without a compile-time type error.

This means that if you have two methods MyClass(one with CharSequence and another with String type argument) which are valid for a call MyClass(null), it will choose the String one because String Implements ( for general Classes case either Implements or Extends) CharSequence so linking it to String will give no error even if you pass String to a MyClass(CharSequence) method. But you can't do vice versa. Hence a subclass argument method is chosen

There are few more cases. If I add one more method as follows

    MyClass(ArrayList list) {
        System.out.println("Array List");
    }

Now it will be a compile time error because all three (ArrayList, String and CharSequence) doesn't form a type hierarchy (one extends/implements another) causing an ambiguity for compiler. However if I add following rather than above ArrayList method

    MyClass(Object obj) {
        System.out.println("Object");
    }

it will work because String implements CharSequence extends Object, So an String can be casted to both hence compiler can choose String argument method for linking.

One more case (might not be that interesting)

Adding following won't create a problem because primitive type is not applicable for null so this method will be removed in first pass of complier for applicable methods.

    MyClass(int i) {
        System.out.println("int");
    }

however following is an object and hence will create ambiguity problem

    MyClass(Integer i) {
        System.out.println("Integer wrapper");
    }

Example above is taken from following link

[1] http://stackoverflow.com/questions/2659496/how-does-polymorph-ambiguity-distinction-work