Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Custom components with Spring 2.5

A hands-on introduction to Spring's flexible component model

By Jeff Hanson, JavaWorld.com, 02/26/08

Page 3 of 5

Implement a custom bean definition parser

Next, you must provide a bean definition parser to the Spring container to handle the parsing of bean configuration data for each top-level element defined in the component's XSD file.

Again, Spring provides a number of convenience classes that handle much of the default processing for a simple component definition. The AbstractSimpleBeanDefinitionParser is a convenience class to use when there is a one-to-one mapping between the component class properties and attributes of the element to be parsed. Given that this is true of our component I can use the simple bean definition parser as shown in Listing 4.

Listing 4. AbstractSimpleBeanDefinitionParser handles a one-to-one mapping

private static class FoobarBeanDefinitionParser
  extends org.springframework.beans.factory.xml.AbstractSimpleBeanDefinitionParser
{
  protected Class getBeanClass(Element element)
  {
    return Foobar.class;
  }
}

With a simple component such as the one defined in this article, the only requirement for a subclass of AbstractSimpleBeanDefinitionParser is to return the class that defines the actual implementation of the component; in this case, the Foobar class.

Define two deployment descriptor files

With the component defined and implemented and the namespace handler and parser is in place, you're ready to give the Spring framework the information it needs to consume the component. This is accomplished by registering the namespace handler and XSD file with Spring using two specialized properties files:

• spring.handlers: A key-value-pair properties file containing a mapping of XML Schema URIs to namespace handler classes. For the Foobar component this is defined as:

  http\://www.jeffhanson.com/schema/service/foobar=com.jeffhanson.spring.beans.
  FoobarNamespaceHandler
  

  Notice that the definition maps the namespace with the namespace-handler class.
• spring.schemas: A key-value-pair properties file containing a mapping of XML schema locations to XSD file. This allows Spring to find the definition on the classpath. For the Foobar component, this file contains:

  http\://www.jeffhanson.com/schema/service/foobar/foobar.xsd=com/jeffhanson/
  spring/beans/foobar.xsd
  

The two files are to be located in the META-INF directory of the .jar file that will contain the component.

With the bean logic, namespace handler, bean definition parser, and deployment-descriptor properties files in place, you are at the last step in developing a Spring component: compiling and packaging the component for distribution.