Spring can be used in standard applications, web applications, full Java EE applications, and other containers, the only requirement is that you run a standard JVM. Spring's resource abstraction allows you to load configuration files from wherever you'd like -- the classpath, the file system, FTP, and HTTP locations. You can also use Spring's resource abstraction for loading other files required for your application.
Once the IoC container is initialized, you can retrieve your Spring beans. By delegating as much bean creation as possible to Spring, there should only be a few key points where the application code needs to directly access the IoC container, and this is true even for legacy applications. [5] If you're developing a web application, you may not need to directly access the IoC container at all since it will automatically handle instantiation of your controller and any beans it requires.
The lowest level implementation of the IoC container is the BeanFactory, but it is recommended to use an ApplicationContext for your application.
The ApplicationContext is a subclass of the BeanFactory interface so it has all the functionality a BeanFactory has and more.
Unless you are writing an application that needs an extremely small memory footprint, BeanFactory shouldn't be used directly.
There are a few different ApplicationContext implementations that can be used, which can be learned about by reading the Spring Framework's documentation
and source code. For the purposes of this example, we'll use a very popular one –ClassPathXmlApplicationContext, which defaults
to reading resources from the classpath. If you need to use a different location for your classes, you can append prefixes before
the configuration file's path such as 'file', 'http', etc. This will force the ApplicationContext to read from somewhere other than the default location.
Example 4. MessageRunner
The following class is a standard Java application with a main method. The first line of the main method
creates a ClassPathXmlApplicationContext passing in '/application-context.xml' to its constructor which
is assigned to the ApplicationContext interface. In this case the configuration file is in the root of the classpath.
The ApplicationContext's getBean(String beanName) method is used on the next line to retrieve the message bean from the IoC container.
public class MessageRunner {
final static Logger logger = LoggerFactory.getLogger(MessageRunner.class);
/**
* Main method.
*/
public static void main(String[] args) {
logger.info("Initializing Spring context.");
ApplicationContext applicationContext = new ClassPathXmlApplicationContext("/application-context.xml");
logger.info("Spring context initialized.");
Message message = (Message) applicationContext.getBean("message");
logger.debug("message='" + message.getMessage() + "'");
}
}
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="message"
class="org.springbyexample.di.app.Message">
<property name="message" value="Spring is fun." />
</bean>
</beans>
[5] Instantiating Spring in your application does not violate rule #1 of dependency inversion (see Spring In Context: Core Concepts) because Spring would be a higher level dependency.