March 2010


Advertisements

Spring provides two type of Spring IOC container : BeanFactory and ApplicationContext.

Bean Factory

  • Bean instantiation/wiring

Application Context

  • Bean instantiation/wiring
  • Automatic BeanPostProcessor registration
  • Automatic BeanFactoryPostProcessor registration
  • Convenient MessageSource access (for i18n)
  • ApplicationEvent publication

Before (Spring 2.0 and earlier):

<bean id="propertyConfigurer">
 <property name="location">
  <value>file:${user.home}/env.properties</value>
 </property>
</bean>

After (Spring 2.5):

1.Loading 1 property file:

<context:property-placeholder location=”file:${user.home}/env.properties”/>

2.Loading multiple properties files:

<bean class=”org.springframework.beans.factory.config.PropertyPlaceholderConfigurer”>

<property name=”locations”>

<list>
<value>classpath:file1</value>
<value>classpath:file2</value>
</list>

</property>

</bean>

*Other property:

-ignoreResourceNotFound

-ignoreUnresolvablePlaceholders

Spring application context loading tricks
By Ben, on May 13th, 2008
The Spring classpath:-notation

As most of you probably know, the Spring Framework can load all sorts of resources into its application context from all sorts of sources. Especially it can do this from the classpath and the people over at SpringSource have even introduced their own URI “protocol” to make this easy: you can identify resources using the classpath-URIs, like so:

classpath:

Most of you are probably familiar with this notation, because it is often used when loading the application context files themselves using the ContextLoaderListener.

What many people don’t realize, is that the classpath:-notation is far more versatile than just for use as a standard URI, because you can use wildcards. In fact I only recently learned this myself from a colleague (at least in part) — which is kind of dumb, because it’s mentioned quite clearly in the documentation.

The first thing you can do above and beyond loading resources by their full path (relative to the classpath) is use all the Ant-style wildcards. So instead of loading as follows:

contextConfigLocation

classpath:businessContext.xml
classpath:persistenceContext.xml
classpath:webFlowBeansContext.xml
classpath:etc.

you can simply load as follows:

contextConfigLocation

classpath:*Context.xml

or, as the case may be:

contextConfigLocation

classpath:**/*Context.xml

There is a catch to this strategy, however: if you have multiple resource repositories (directories, databases, online resources, whatever) on your classpath containing files that match your wildcard pattern, Spring will only look for matching resources in one of these locations. To illustrate this for yourself, try using maven to create a standard project structure, then put a context file in src/main/resources and src/test/resources and try to load both at the same time with a wildcard — you’ll only get one.

The classpath*:-notation

Of course the Spring guys wouldn’t be the Spring guys if they didn’t have a simple solution for this problem. It’s called the classpath*:-notation. Simply put, if you rewrite the snippet from above like so:

contextConfigLocation

classpath*:**/*Context.xml

then Spring will load every matching context file from the entire classpath.

As the documentation points out, the combination of the classpath*:-notation with Ant-style wildcards makes it possible to organize your application into a neat component-assembly style: you can put all the code for each individual problem from your problem domain into its own component (a jar, say) and then “slot” as many jars into place as you like to make your application. You can even add components later on without making major adjustments to any other component (if you think about it carefully). Just make sure each component has an application context file that follows the general naming schema. Think of the possibilities if you include OSGi or even the new Service Provider spec.

Caveat emptor

There is a very specific sort of naming pattern that you can also create using the classpath*:-notation. This is the naming pattern whereby all application context files within the application have exactly the same name (e.g. classpath*:myAppContext.xml). This pattern allows you to expand your context completely transparently to all others without even having to think very hard about the naming convention.

DO NOT EVER, EVER, EVER, EVER, EVER, EVER, EVER, EVER, EVER, EVER, EVER, EVER DO THIS!!!

If you give all your context files the same name, you lose precise control over what gets loaded and what doesn’t. This can hurt if you create components that you want to reuse across applications (especially if you are using Maven and have transitive dependenciesto deal with) and it can hurt in creating integration tests that involve partially loaded contexts. It also makes it harder to find naming conflicts in your contexts if you introduce them accidentally (especially if you are not the only developer on your project). Always make sure each context file on the classpath has a unique name!
Conclusion

The Spring Framework includes a very flexible notation for loading resources from the classpath, using wildcards to identify resources. This notation, if used correctly, gives you considerable freedom in creating component-assembly style applications. However, you must still guard against using unwise naming of your context files.

Table 4.1. Resource strings

Prefix Example Explanation
classpath: classpath:com/myapp/config.xml Loaded from the classpath.
file: file:/data/config.xml Loaded as a URL, from the
filesystem.
http: http://myserver/logo.png Loaded as a
URL.
(none) /data/config.xml Depends on the underlying
ApplicationContext.

An entity is essentially a noun, or a grouping of state
associated together as a single unit. It may participate in relationships to any number of other entities in a number of standard ways. In the object-oriented paradigm, we would add behavior to it and call it an object.

Characteristic of entity :
-Persistability
-Identity
-Transactionality
-Granularity

Dependency Scope

Dependency scope is used to limit the transitivity of a depedency, and also to affect the classpath used for various build tasks.

There are 6 scopes available:

  • compile
    This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
  • provided
    This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
  • runtime
    This scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
  • test
    This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases.
  • system
    This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.
  • import (only available in Maven 2.0.9 or later)
    This scope is only used on a dependency of type pom in the <dependencyManagement> section. It indicates that the specified POM should be replaced with the dependencies in that POM’s <dependencyManagement> section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.

Next Page »