Declarative Usage of Application Contexts

[Himalay Majumdar]

Programmatic Usage of Application Contexts


ApplicationContext ctx= new ClassPathXmlApplicationContext("ch03/sample2/applicationContext.xml");

Once the bean factory or application context has been loaded, accessing beans in a basic fashion is as simple as using getBean() from the BeanFactory interface:

WeatherService ws = (WeatherService) ctx.getBean("weatherService");



Declarative Usage of Application Contexts as in (From: Professional Java Development with the Spring Framework)

Following IoC principles, as little application code as possible should know about the application context. We've mentioned that in spite of these principles, it is sometimes necessary for a small amount of glue code to know about the context. For a Spring-enabled J2EE web-app, it is possible to reduce or completely eliminate even this small amount of code by using Spring code to declaratively specify that an application context should be loaded at web-app startup.Spring's ContextLoader is the class that provides this capability.

At this time, containers known to work with the listener approach are Apache Tomcat 4.x+, Jetty 4.x+, Resin 2.1.8+, JBoss 3.0+, WebLogic 8.1 SP3+, and Orion 2.0.2+.
Containers known to not work with the listener approach, and which need the servlet approach, are BEA WebLogic up to 8.1 SP2, IBM WebSphere up to 5.x, and Oracle OC4J up to 9.0.x.

ContextLoaderListener is configured via a <listener> element in the standard J2EE web.xml file that is part of every web-app:

...
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-
class>
</listener>
...

Setting up ContextLoaderServlet instead is done via the <servlet> element in the web.xml file:

<servlet>
<servlet-name>context</servlet-name>
<servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-
class>
<load-on-startup>1</load-on-startup>
</servlet>

Having done this declarative set-up, how can I access each individual bean?..i.e, doing something similar to getBean() method in programmatic approach.

Thank you,
Himalay

[Hong Anderson]

You're supposed to use DI, not getBean. Try to use Spring Web MVC, you'll understand.

[Himalay Majumdar]

Thanks for looking into it Kengkaj.

I have followed This Link.
I understood that we inject dependencies using Spring Configuration File, but finally we need to use getbean.

i.e,

ClassPathXmlApplicationContext appContext = new ClassPathXmlApplicationContext(new String[] { "springexample-creditaccount.xml" });
CreateCreditCardAccountInterface creditCardAccount = (CreateCreditCardAccountInterface)appContext.getBean("createCreditCard");

Please correct me, if you can point me to an example, that would be great.

-Himalay

[Hong Anderson]

No we don't need getBean, we should not use getBean.
ContextLoaderListener loads applicationContext, we can use DI.

[Nandeesh Satishkumar]

My understanding is...
In case of a web application one can use the contextLoaderListener to load the spring configuration files. I would prefer this approach as spring does the job for me of creating the Application context. So in this example below...

<!--------- In Web.xml ----------->

<context-param>
	<param-name>contextConfigLocation</param-name>
	<param-value>/com/test/spring/applicationContext1.xml</param-value>
</context-param>

<listener>
   	<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
               <!-- For Servlet 2.2 containers and Servlet 2.3 ones that do not initalize listeners before servlets, use ContextLoaderServlet -->
</listener>

ContextLoaderListener will look for the param contextConfigLocation and load the configuration files used in the value, in this case applicationContext1. So if later I want to change the path of my applicationContext1.xml I can do it here with out any re-compilation of code required. So internally appContext is created by spring for me.

One has to get hands on to this context to extract the beans of the applicationContext1.xml. One way I think this can be acheived is the use of ApplicationContextAware interface. An example of this usage is given here http://jerlinworld.wordpress.com/2009/07/20/making-your-spring-application-context-aware/. Once access to the context is available one can created a Factory class and using the getBean method on the context beans can be extraceted from applicationContext1.xml.

The usage of getBean is the required glue code between spring and your application. DI is just a concept of injecting resources in to bean so that the bean is avaialble ready to use out of the box.

[Hong Anderson]

Nandeesh Satishkumar wrote:
The usage of getBean is the required glue code between spring and your application.

Not always true. In web applications, we should not use a single getBean. Using getBean will tie code to Spring Framework which should be avoid if possible.
If you use Spring Web MVC, you can specify Spring Web MVC controllers in *-servlet.xml and you can just use DI.

[Himalay Majumdar]

Consider this example from Professional Java Development with the Spring Framework

public interface WeatherService {
   Double getHistoricalHigh(Date date);
}
   
public class WeatherServiceImpl implements WeatherService {
    
  private WeatherDAO weatherDao;
    
  public void setWeatherDao(WeatherDAO weatherDao) {
    this.weatherDao = weatherDao;
  }
    
  public Double getHistoricalHigh(Date date) {
    WeatherData wd = weatherDao.find(date);
    if (wd != null)
      return new Double(wd.getHigh());
    return null;
  }
}



public interface WeatherDAO {
  WeatherData find(Date date);
  WeatherData save(Date date);
  WeatherData update(Date date);
}
    
public class StaticDataWeatherDAOImpl implements WeatherDAO {
    
  public WeatherData find(Date date) {
    WeatherData wd = new WeatherData();
    wd.setDate((Date) date.clone());
    ...
    return wd;
  }
    
  public WeatherData save(Date date) {
    ...
  }
  public WeatherData update(Date date) {
    ...
  }
}



<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
    "http://www.springframework.org/dtd/spring-beans.dtd">
    
<beans>
  <bean id="weatherService" class="ch02.sample2.WeatherServiceImpl">
    <property name="weatherDao">
      <ref local="weatherDao"/>
    </property>
  </bean>
  <bean id="weatherDao" class="ch02.sample2.StaticDataWeatherDaoImpl">
  </bean>
</beans>


// Out of the box testing using getBean

public class WeatherServiceTest extends TestCase {
  public void testSample2() throws Exception {
    ApplicationContext ctx = new ClassPathXmlApplicationContext(
        "ch03/sample2/applicationContext.xml");
    WeatherService ws = (WeatherService) ctx.getBean("weatherService");
   
    Double high = ws.getHistoricalHigh(
        new GregorianCalendar(2004, 0, 1).getTime());
    // ... do more validation of returned value here... 
  }
}

Do you mean I should not use getBean in the above case, can you demonstrate with an example?

[Hong Anderson]

You should try to use Spring Web MVC as I suggested, you'll immediately understand.

Using getBean in test code is fine. But we should not use a single getBean in web applications.
ContextLoaderListener will instantiate an application context, and application context will pre-instantiate singleton beans and inject dependencies to beans defined in bean definition. There is no need to use getBean.

[Ben Narendren]

I agree that we don't have a use for getBean in a regular scenario like if we are using Spring MVC. But there are situations where getBean can come handy. I remember doing a EJB facade over the spring layer and the Spring MVC interacted with this EJB facade. Here the EJB facade has no managed access to the business layer and it had to use getBean (using ApplicationContextAware) to access the spring beans.

[Hong Anderson]

I don't know what you mean by EJB facade over Spring, could you please to explain more?

[Ben Narendren]

Please take a look at this java world article on EJB facades over Spring Business services

http://www.javaworld.com/javaworld/jw-02-2005/jw-0214-springejb.html

This piece of code which you will find in the article is an example of where getBean() is called instead of DI

public class EchoServiceEJB extends AbstractStatelessSessionBean implements EchoService {
   private static final String BEAN_NAME = "echoService";  
   private EchoService service;   
   
   public String echo(String message) {
      return service.echo(message);
   }  

   protected void onEjbCreate() throws CreateException {
      service = (EchoService) getBeanFactory().getBean(BEAN_NAME);
   }
}