For example, to add a logging functionality to the News Feed service, something similar to this XML can be used:

<bean id=" ShowNews" class="com.example.ShowNews">
</bean>
<bean id="myLogger" class="com.example.MyLogger">
   <property name="someProperty">
      <value>Custom string property value</value>
   </property>
</bean>
<bean id="debugInterceptor"
      class="org.springframework.aop.interceptor.DebugInterceptor">
</bean>
<bean id="news"
      class="org.springframework.aop.framework.ProxyFactoryBean">
   <property name="proxyInterfaces">
      <value>com.example.ShowNews</value>
   </property>
   <property name="target">
      <ref local="ShowNews"/>
   </property>
   <property name="interceptorNames">
      <list>
         <value>myLogger</value>
         <value>debugInterceptor</value>
      </list>
   </property>
</bean>

Note: The interceptorNames property takes a list of String: the bean names of the interceptor or aspects in the current factory. Also, note the myLogger bean has a primitive string property set in XML as an example.

Spring provides a lot of functionality to wire beans in XML, such as injecting other beans via setters or constructors, setting primitive bean properties, setting collections of bean properties, and using AOP aspects. It can even auto-wire the beans by type or name. All of these features, in particular AOP, are provided by the Spring to eliminate the need to use EJBs. The transactions, security, and any other business rule can be woven as an aspect by using the Spring container.

Devil’s Advocate Discussion

Now, return to the questions of industry support. Who should use Spring and what is involved to implement this technology in an enterprise project? As of this writing, Spring is not supported by any major IDE vendor. There is a stable third-party plug-in for Eclipse, but if you are using any other IDE, you are out of luck. The limited support means that there is no easy (or visual) way to generate configuration XML, which can be quite extensive in a large enterprise application with hundreds of beans and aspects, and thousands of properties. Even complex EJBs can be created visually with any modern IDE, and their code and configuration can be auto generated. To implement Spring in an enterprise project, developers need to learn the "XML language" of Spring configuration, bean wiring, and AOP and then code in both Java and XML. The IDE will not help unless the company adopts Eclipse as a standard, but even after that, a lot of XML will be coded by hand.

Spring’s Web module also is configured via XML and with limited support in IDEs creating a Web application based on Spring, MVC can be a much longer and error-prone process. This can be compared to the JavaServer Faces framework, which offers visual application flow creation and auto XML config generation in most of the IDEs that support it.

Conclusion

In this article, I talked about the Spring framework. I have looked at its features, concepts, and usability. Despite the elegance and eclectic structure of the framework, my biggest concern is the limited industry support and heavy reliance on XML, which is a two-edged sword of the framework. On one hand, XML is the glue and makes the framework truly powerful; on the other, such complex XML should not be written by hand. Unfortunately, without proper tool support, there is not way around it at the moment. Having said that, I believe that Spring offers many useful modules and concepts, and investing some time to learn them can be beneficial. It will be interesting to see what will happen to this technology with the arrival of EJB3 and continued evolution of the other frameworks.

References

About the Author

Vlad Kofman is a Senior System Architect. He has implemented enterprise-scale projects for the major Wall Street firms, defense contracts, and the U.S. government. His main interests are object-oriented programming methodologies and the design patterns