Contents

OOPS - An Overview

          OOP, or Object Oriented Programming, is one of the best programming concept invented -- just as good as the multitasking OS and compiled libraries. OOP is really just trying to model individual objects in the world.

Click here : Object Oriented Programming tutorials

Java Tutorials For Beginners

         Java has evolved to be the most predominant and popular general purpose programming language of the current age. Java is a simple, portable, distributed, robust, secure, dynamic, architecture neutral, object oriented programming language. It was developed by Sun Microsystems. This technology allows the software designed and developed once for an idealized ‘virtual machine’ and run on various computing platforms. 

Click here : Java tutorials

Spring framework - Beginners tutorial

       Spring is modular and has been divided logically into independent packages, which can function independently. The architects of an application have the flexibility to implement just a few spring packages and leave out most of the packages in spring.

Click here : Spring tutorials 

Openlaszlo - An alternative to FLEX 

  
      Openlaszlo is a similar technology to FLEX using XML and JavaScript, but based on the idea of open source.

Click here : Openlaszlo tutorials 

ibatis - Persistence Framework 

     The iBatis framework is a lightweight data mapping framework and persistence API that can be used to quickly leverage a legacy database schema to generate a database persistence layer for your Java application.

Click here : Ibatis tutorials 

Images

How to Debug in Openlaszlo

All who used openlaszlo knows that its very difficult to debug each statements. The one way is to put alert statements. But we have to create different alert object, that too statically, so as to find what is happening or whats the current value. This is practical only in case of small applications. But in case of big applications, this will not be practical. So please try the below example. Here all the lines we wanted will be displayed one after the other. Thus we can check different scenarios.

<window  x="${parent.width - 400}" width="400" height="200" name="Ajith" visible="true" id="DebugWindow" oninit="bringToFront()" resizable="true">

<edittext name="Debugger" id="debuggertext" multiline="true" width="${parent.width-20}" height="${parent.height-65}" text="--Start of Debug Statements--" y="20">

   <handler name="oninit">

       this.field['fakeScroll'] = this.field['scroll'];

       var del = new LzDelegate(this, "doScroll");

       del.register(this.field, "onfakeScroll");

   </handler>

   <handler name="onscroll" reference="field">

      if (field.scroll != field.fakeScroll) {

        field.setAttribute('fakeScroll', (field.scroll - 1) * -1);

      }

    </handler>

   <method name="doScroll" args="arg">

      field.setScroll((-1 * field.fakeScroll) + 1);

   </method>

   <scrollbar scrolltarget="parent.field" scrollattr="fakeScroll"    scrollmax="${parent.field.maxscroll+parent.height-1}" stepsize="1" name="scroller" align="right"/>

   

</edittext>

<method name="write" args="p">

   var today_date = new Date();

   var today_datef = today_date.getHours() + ":"+ today_date.getMinutes() + ":" + today_date.getSeconds()+ ":" + today_date.getMilliseconds() + "ms";

   this.Debugger.setAttribute('text', this.Debugger['text'] + "\n" + today_datef +"  "+p);

   this.Debugger.setSelection(0,this.Debugger['text'].length);

   return;

</method>

 

<button>clear

  <handler name="onclick">

            debuggertext.setAttribute("text","");

  </handler>

 </button>

</window>

And just use the below statement to print your message :

   DebugWindow.write(" your message "); 

   The debugger will also give the time at which each statement will execute. This will be useful  in case of performance checking.

Hope you guys will enjoy debugging using the above code. Please do give your valuable suggestions

Summary

Spring is a powerful framework that solves many common problems in J2EE. Many Spring features are also usable in a wide range of Java environments, beyond classic J2EE.

Spring provides a consistent way of managing business objects and encourages good practices such as programming to interfaces, rather than classes. The architectural basis of Spring is an Inversion of Control container based around the use of JavaBean properties. However, this is only part of the overall picture: Spring is unique in that it uses its IoC container as the basic building block in a comprehensive solution that addresses all architectural tiers.

Spring provides a unique data access abstraction, including a simple and productive JDBC framework that greatly improves productivity and reduces the likelihood of errors. Spring's data access architecture also integrates with TopLink, Hibernate, JDO and other O/R mapping solutions.

Spring also provides a unique transaction management abstraction, which enables a consistent programming model over a variety of underlying transaction technologies, such as JTA or JDBC.

Spring provides an AOP framework written in standard Java, which provides declarative transaction management and other enterprise services to be applied to POJOs or - if you wish - the ability to implement your own custom aspects. This framework is powerful enough to enable many applications to dispense with the complexity of EJB, while enjoying key services traditionally associated with EJB.

Spring also provides a powerful and flexible MVC web framework that is integrated into the overall IoC container.

Testing

As you've probably gathered, I and the other Spring developers are firm believers in the importance of comprehensive unit testing. We believe that it's essential that frameworks are thoroughly unit tested, and that a prime goal of framework design should be to make applications built on the framework easy to unit test.

Spring itself has an excellent unit test suite. We've found the benefits of test first development to be very real on this project. For example, it has made working as an internationally distributed team extremely efficient, and users comment that CVS snapshots tend to be stable and safe to use.

We believe that applications built on Spring are very easy to test, for the following reasons:

• IoC facilitates unit testing
• Applications don't contain plumbing code directly using J2EE services such as JNDI, which is typically hard to test
• Spring bean factories or contexts can be set up outside a container

The ability to set up a Spring bean factory outside a container offers interesting options for the development process. In several web application projects using Spring, work has started by defining the business interfaces and integration testing their implementation outside a web container. Only after business functionality is substantially complete is a thin layer added to provide a web interface.

Since Spring 1.1.1, Spring has provided powerful and unique support for a form of integration testing outside the deployed environment. This is not intended as a substitute for unit testing or testing against the deployed environment. However, it can significantly improve productivity.

The org.springframework.test package provides valuable superclasses for integration tests using a Spring container, but not dependent on an application server or other deployed environment. Such tests can run in JUnit--even in an IDE--without any special deployment step. They will be slower to run than unit tests, but much faster to run than Cactus tests or remote tests relying on deployment to an application server. Typically it is possible to run hundreds of tests hitting a development database--usually not an embedded database, but the product used in production--within seconds, rather than minutes or hours. Such tests can quickly verify correct wiring of your Spring contexts, and data access using JDBC or ORM tool, such as correctness of SQL statements. For example, you can test your DAO implementation classes.

The enabling functionality in the org.springframework.test package includes:

• The ability to populate JUnit test cases via Dependency Injection. This makes it possible to reuse Spring XML configuration when testing, and eliminates the need for custom setup code for tests.
• The ability to cache container configuration between test cases, which greatly increases performance where slow-to-initialize resources such as JDBC connection pools or Hibernate SessionFactories are concerned.
• Infrastructure to create a transaction around each test method and roll it back at the conclusion of the test by default. This makes it possible for tests to perform any kind of data access without worrying about the effect on the environments of other tests. In my experience across several complex projects using this functionality, the productivity and speed gain of such a rollback-based approach is very significant. 
  
  
  Next : Summary 

Implementing EJBs

If you choose to use EJB, Spring can provide important benefits in both EJB implementation and client-side access to EJBs.

It's now widely regarded as a best practice to refactor business logic into POJOs behind EJB facades. (Among other things, this makes it much easier to unit test business logic, as EJBs depend heavily on the container and are hard to test in isolation.) Spring provides convenient superclasses for session beans and message driven beans that make this very easy, by automatically loading a BeanFactory based on an XML document included in the EJB Jar file.

This means that a stateless session EJB might obtain and use a collaborator like this:

import org.springframework.ejb.support.AbstractStatelessSessionBean;

public class MyEJB extends AbstractStatelessSessionBean
implements MyBusinessInterface {
       private MyPOJO myPOJO;

       protected void onEjbCreate() {
              this.myPOJO = getBeanFactory().getBean("myPOJO");
       }

       public void myBusinessMethod() {
              this.myPOJO.invokeMethod();
       }
}

Assuming that MyPOJO is an interface, the implementing class - and any configuration it requires, such as primitive properties and further collaborators - is hidden in the XML bean factory definition.

We tell Spring where to load the XML document via an environment variable definition named ejb/BeanFactoryPath in the standard ejb-jar.xml deployment descriptor, as follows:

<session>
    <ejb-name>myComponent</ejb-name>
    <local-home>com.test.ejb.myEjbBeanLocalHome</local-home>
    <local>com.mycom.MyComponentLocal</local>
    <ejb-class>com.mycom.MyComponentEJB</ejb-class>
    <session-type>Stateless</session-type>
    <transaction-type>Container</transaction-type>

   <env-entry>
        <env-entry-name>ejb/BeanFactoryPath</env-entry-name>
        <env-entry-type>java.lang.String</env-entry-type>
        <env-entry-value>/myComponent-ejb-beans.xml</env-entry-value>
   </env-entry>
</session>

The myComponent-ejb-beans.xml file will be loaded from the classpath: in this case, in the root of the EJB Jar file. Each EJB can specify its own XML document, so this mechanism can be used multiple times per EJB Jar file.

The Spring superclasses implement EJB lifecycle methods such as setSessionContext() and ejbCreate(), leaving the application developer to optionally implement the Spring onEjbCreate() method.

When EJB 3.0 is available in public draft, we will offer support for the use of the Spring IoC container to provide richer Dependency Injection semantics in that environment. We will also integrate the JSR-220 O/R mapping API with Spring as a supported data access API.

Using EJBs

Spring also makes it much easier to use, as well as implement EJBs. Many EJB applications use the Service Locator and Business Delegate patterns. These are better than spraying JNDI lookups throughout client code, but their usual implementations have significant disadvantages. For example:

• Typically code using EJBs depends on Service Locator or Business Delegate singletons, making it hard to test.
• In the case of the Service Locator pattern used without a Business Delegate, application code still ends up having to invoke the create() method on an EJB home, and deal with the resulting exceptions. Thus it remains tied to the EJB API and the complexity of the EJB programming model.
• Implementing the Business Delegate pattern typically results in significant code duplication, where we have to write numerous methods that simply call the same method on the EJB.

For these and other reasons, traditional EJB access, as demonstrated in applications such as the Sun Adventure Builder and OTN J2EE Virtual Shopping Mall, can reduce productivity and result in significant complexity.

Spring steps beyond this by introducing codeless business delegates. With Spring you'll never need to write another Service Locator, another JNDI lookup, or duplicate methods in a hand-coded Business Delegate unless you're adding real value.

For example, imagine that we have a web controller that uses a local EJB. We'll follow best practice and use the EJB Business Methods Interface pattern, so that the EJB's local interface extends a non EJB-specific business methods interface. (One of the main reasons to do this is to ensure that synchronization between method signatures in local interface and bean implementation class is automatic.) Let's call this business methods interface MyComponent. Of course we'll also need to implement the local home interface and provide a bean implementation class that implements SessionBean and the MyComponent business methods interface.

With Spring EJB access, the only Java coding we'll need to do to hook up our web tier controller to the EJB implementation is to expose a setter method of type MyComponent on our controller. This will save the reference as an instance variable like this:

private MyComponent myComponent;

public void setMyComponent(MyComponent myComponent) {
      this.myComponent = myComponent;
}

We can subsequently use this instance variable in any business method.

Spring does the rest of the work automatically, via XML bean definition entries like this. LocalStatelessSessionProxyFactoryBean is a generic factory bean that can be used for any EJB. The object it creates can be cast by Spring to the MyComponent type automatically.

<bean id="myComponent"
class="org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean">
      <property name="jndiName" value="myComponent" />
      <property name="businessInterface" value="com.mycom.MyComponent" />
</bean>

<bean id="myController" class = "com.mycom.myController">
       <property name="myComponent" ref="myComponent"/> </bean>                                                                                                                    

There's a lot of magic happening behind the scenes, courtesy of the Spring AOP framework, although you aren't forced to work with AOP concepts to enjoy the results. The "myComponent" bean definition creates a proxy for the EJB, which implements the business method interface. The EJB local home is cached on startup, so there's normally only a single JNDI lookup. (There is also support for retry on failure, so an EJB redeployment won't cause the client to fail.) Each time the EJB is invoked, the proxy invokes the create() method on the local EJB and invokes the corresponding business method on the EJB.

The myController bean definition sets the myController property of the controller class to this proxy.

This EJB access mechanism delivers huge simplification of application code:

• The web tier code has no dependence on the use of EJB. If we want to replace this EJB reference with a POJO or a mock object or other test stub, we could simply change the myComponent bean definition without changing a line of Java code
• We haven't had to write a single line of JNDI lookup or other EJB plumbing code as part of our application.

We can also apply the same approach to remote EJBs, via the similar org.springframework.ejb.access.SimpleRemoteStatelessSessionProxyFactoryBean factory bean. However, it's trickier to conceal the RemoteExceptions on the business methods interface of a remote EJB. (Spring does let you do this, if you wish to provide a client-side service interface that matches the EJB remote interface but without the "throws RemoteException" clause in the method signatures.) 


Next : Testing 

MVC web framework

Spring includes a powerful and highly configurable MVC web framework.

Spring's MVC model is most similar to that of Struts, although it is not derived from Struts. A Spring Controller is similar to a Struts Action in that it is a multithreaded service object, with a single instance executing on behalf of all clients. However, we believe that Spring MVC has some significant advantages over Struts. For example:

• Spring provides a very clean division between controllers, JavaBean models, and views.
• Spring's MVC is very flexible. Unlike Struts, which forces your Action and Form objects into concrete inheritance (thus taking away your single shot at concrete inheritance in Java), Spring MVC is entirely based on interfaces. Furthermore, just about every part of the Spring MVC framework is configurable via plugging in your own interface. Of course we also provide convenience classes as an implementation option.
• Spring, like WebWork, provides interceptors as well as controllers, making it easy to factor out behavior common to the handling of many requests.
• Spring MVC is truly view-agnostic. You don't get pushed to use JSP if you don't want to; you can use Velocity, XLST or other view technologies. If you want to use a custom view mechanism - for example, your own templating language - you can easily implement the Spring View interface to integrate it.
• Spring Controllers are configured via IoC like any other objects. This makes them easy to test, and beautifully integrated with other objects managed by Spring.
• Spring MVC web tiers are typically easier to test than Struts web tiers, due to the avoidance of forced concrete inheritance and explicit dependence of controllers on the dispatcher servlet.
• The web tier becomes a thin layer on top of a business object layer. This encourages good practice. Struts and other dedicated web frameworks leave you on your own in implementing your business objects; Spring provides an integrated framework for all tiers of your application.

As in Struts 1.1 and above, you can have as many dispatcher servlets as you need in a Spring MVC application.

The following example shows how a simple Spring Controller can access business objects defined in the same application context. This controller performs a search in its handleRequest() method:

public class GMSearchController
implements Controller {

private IGMSearchPort gm;

private String gmKey;

public void setGM(IGMSearchPort gm) {
      this.gm = gm;
}

public void setGMKey(String gmKey) {
      this.gmKey = gmKey;
}

public ModelAndView handleRequest(
HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
      String query = request.getParameter("query");
     GMSearchResult result =
     // GM property definitions omitted...

     // Use gm business object
      gm.doGMSearch(this.gmKey, query, start, maxResults, filter,restrict,safeSearch, lr, ie, oe);
      return new ModelAndView("gmResults", "result", result);
      }
}

In the prototype this code is taken from, IGMSearchPort is a GLUE web services proxy, returned by a Spring FactoryBean. However, Spring IoC isolates this controller from the underlying web services library. The interface could equally be implemented by a plain Java object, test stub, mock object, or EJB proxy, as discussed below. This controller contains no resource lookup; nothing except code necessary to support its web interaction.

Spring also provides support for data binding, forms, wizards and more complex workflow. A forthcoming article in this series will discuss Spring MVC in detail.

If your requirements are really complex, you should consider Spring Web Flow, a powerful framework that provides a higher level of abstraction for web flows than any traditional web MVC framework, and was discussed in a recent TSS article by its architect, Keith Donald.

A good introduction to the Spring MVC framework is Thomas Risberg's Spring MVC tutorial (http://www.springframework.org/docs/MVC-step-by-step/Spring-MVC-step-by-step.html). See also "Web MVC with the Spring Framework" (http://www.springframework.org/docs/web_mvc.html).

If you're happy with your favourite MVC framework, Spring's layered infrastructure allows you to use the rest of Spring without our MVC layer. We have Spring users who use Spring for middle tier management and data access but use Struts, WebWork, Tapestry or JSF in the web tier. 

Next : Implementing EJBs 

AOP

Since 2003 there has been much interest in applying AOP solutions to those enterprise concerns, such as transaction management, which have traditionally been addressed by EJB.

The first goal of Spring's AOP support is to provide J2EE services to POJOs. Spring AOP is portable between application servers, so there's no risk of vendor lock in. It works in either web or EJB container, and has been used successfully in WebLogic, Tomcat, JBoss, Resin, Jetty, Orion and many other application servers and web containers.

Spring AOP supports method interception. Key AOP concepts supported include:

• Interception: Custom behaviour can be inserted before or after method invocations against any interface or class. This is similar to "around advice" in AspectJ terminology.
• Introduction: Specifying that an advice should cause an object to implement additional interfaces. This can amount to mixin inheritance.
• Static and dynamic pointcuts: Specifying the points in program execution at which interception should take place. Static pointcuts concern method signatures; dynamic pointcuts may also consider method arguments at the point where they are evaluated. Pointcuts are defined separately from interceptors, enabling a standard interceptor to be applied in different applications and code contexts.

Spring supports both stateful (one instance per advised object) and stateless interceptors (one instance for all advice).

Spring does not support field interception. This is a deliberate design decision. I have always felt that field interception violates encapsulation. I prefer to think of AOP as complementing, rather than conflicting with, OOP. In five or ten years time we will probably have travelled a lot farther on the AOP learning curve and feel comfortable giving AOP a seat at the top table of application design. (At that point language-based solutions such as AspectJ may be far more attractive than they are today.)

Spring implements AOP using dynamic proxies (where an interface exists) or CGLIB byte code generation at runtime (which enables proxying of classes). Both these approaches work in any application server, or in a standalone environment.

Spring was the first AOP framework to implement the AOP Alliance interfaces (www.sourceforge.net/projects/aopalliance). These represent an attempt to define interfaces allowing interoperability of interceptors between AOP frameworks.

Spring integrates with AspectJ, providing the ability to seamlessly include AspectJ aspects into Spring applications . Since Spring 1.1 it has been possible to dependency inject AspectJ aspects using the Spring IoC container, just like any Java class. Thus AspectJ aspects can depend on any Spring-managed objects. The integration with the forthcoming AspectJ 5 release is still more exciting, with AspectJ set to provide the ability to dependency inject any POJO using Spring, based on an annotation-driven pointcut.

Because Spring advises objects at instance, rather than class loader, level, it is possible to use multiple instances of the same class with different advice, or use unadvised instances along with advised instances.

Perhaps the commonest use of Spring AOP is for declarative transaction management. This builds on the transaction abstraction described above, and can deliver declarative transaction management on any POJO. Depending on the transaction strategy, the underlying mechanism can be JTA, JDBC, Hibernate or any other API offering transaction management.

The following are the key differences from EJB CMT:

• Transaction management can be applied to any POJO. We recommend that business objects implement interfaces, but this is a matter of good programming practice, and is not enforced by the framework.
• Programmatic rollback can be achieved within a transactional POJO through using the Spring transaction API. We provide static methods for this, using ThreadLocal variables, so you don't need to propagate a context object such as an EJBContext to ensure rollback.
• You can define rollback rules declaratively. Whereas EJB will not automatically roll back a transaction on an uncaught application exception (only on unchecked exceptions, other types of Throwable and "system" exceptions), application developers often want a transaction to roll back on any exception. Spring transaction management allows you to specify declaratively which exceptions and subclasses should cause automatic rollback. Default behaviour is as with EJB, but you can specify automatic rollback on checked, as well as unchecked exceptions. This has the important benefit of minimizing the need for programmatic rollback, which creates a dependence on the Spring transaction API (as EJB programmatic rollback does on the EJBContext).
• Because the underlying Spring transaction abstraction supports savepoints if they are supported by the underlying transaction infrastructure, Spring's declarative transaction management can support nested transactions, in addition to the propagation modes specified by EJB CMT (which Spring supports with identical semantics to EJB). Thus, for example, if you have doing JDBC operations on Oracle, you can use declarative nested transactions using Spring.
• Transaction management is not tied to JTA. As explained above, Spring transaction management can work with different transaction strategies.

It's also possible to use Spring AOP to implement application-specific aspects. Whether or not you choose to do this depends on your level of comfort with AOP concepts, rather than Spring's capabilities, but it can be very useful. Successful examples we've seen include:

• Custom security interception, where the complexity of security checks required is beyond the capability of the standard J2EE security infrastructure. (Of course, before rolling your own security infrastructure, you should check the capabilities of Acegi Security for Spring, a powerful, flexible security framework that integrates with Spring using AOP, and reflects Spring's architectural approach.
• Debugging and profiling aspects for use during development
• Aspects that apply consistent exception handling policies in a single place
• Interceptors that send emails to alert administrators or users of unusual scenarios

Application-specific aspects can be a powerful way of removing the need for boilerplate code across many methods.

Spring AOP integrates transparently with the Spring BeanFactory concept. Code obtaining an object from a Spring BeanFactory doesn't need to know whether or not it is advised. As with any object, the contract will be defined by the interfaces the object implements.

The following XML stanza illustrates how to define an AOP proxy:

<bean id="myTest"
       class="org.springframework.aop.framework.ProxyFactoryBean">
       <property name="proxyInterfaces">
              <value>org.springframework.beans.ITestBean</value>
       </property>
       <property name="interceptorNames">
             <list>
                   <value>txInterceptor</value>
                   <value>target</value>
            </list>
      </property>
</bean>

Note that the class of the bean definition is always the AOP framework's ProxyFactoryBean, although the type of the bean as used in references or returned by the BeanFactory getBean() method will depend on the proxy interfaces. (Multiple proxy methods are supported.) The "interceptorNames" property of the ProxyFactoryBean takes a list of String. (Bean names must be used rather than bean references, as new instances of stateful interceptors may need to be created if the proxy is a "prototype", rather than a singleton bean definition.) The names in this list can be interceptors or pointcuts (interceptors and information about when they should apply). The "target" value in the list above automatically creates an "invoker interceptor" wrapping the target object. It is the name of a bean in the factory that implements the proxy interface. The myTest bean in this example can be used like any other bean in the bean factory. For example, other objects can reference it via <ref> elements and these references will be set by Spring IoC.

There are a number of ways to set up proxying more concisely, if you don't need the full power of the AOP framework, such as using Java 5.0 annotations to drive transactional proxying without XML metadata, or the ability to use a single piece of XML to apply a consistent proxying strategy to many beans defined in a Spring factory.

It's also possible to construct AOP proxies programmatically without using a BeanFactory, although this is more rarely used:

TestBean target = new TestBean();
DebugInterceptor di = new DebugInterceptor();
MyInterceptor mi = new MyInterceptor();
ProxyFactory factory = new ProxyFactory(target);
factory.addInterceptor(0, di);
factory.addInterceptor(1, mi);
// An "invoker interceptor" is automatically added to wrap the target
ITestBean tb = (ITestBean) factory.getProxy();

We believe that it's generally best to externalize the wiring of applications from Java code, and AOP is no exception.

The use of AOP as an alternative to EJB (version 2 or above) for delivering enterprise services is growing in importance. Spring has successfully demonstrated the value proposition.


Next : MVC web framework

O/R mapping integration

Of course often you want to use O/R mapping, rather than use relational data access. Your overall application framework must support this also. Thus Spring integrates out of the box with Hibernate (versions 2 and 3), JDO (versions 1 and 2), TopLink and other ORM products. Its data access architecture allows it to integrate with any underlying data access technology. Spring and Hibernate are a particularly popular combination.

Why would you use an ORM product plus Spring, instead of the ORM product directly? Spring adds significant value in the following areas:

• Session management. Spring offers efficient, easy, and safe handling of units of work such as Hibernate or TopLink Sessions. Related code using the ORM tool alone generally needs to use the same "Session" object for efficiency and proper transaction handling. Spring can transparently create and bind a session to the current thread, using either a declarative, AOP method interceptor approach, or by using an explicit, "template" wrapper class at the Java code level. Thus Spring solves many of the usage issues that affect many users of ORM technology.
• Resource management. Spring application contexts can handle the location and configuration of Hibernate SessionFactories, JDBC datasources, and other related resources. This makes these values easy to manage and change.
• Integrated transaction management. Spring allows you to wrap your ORM code with either a declarative, AOP method interceptor, or an explicit 'template' wrapper class at the Java code level. In either case, transaction semantics are handled for you, and proper transaction handling (rollback, etc.) in case of exceptions is taken care of. As we discuss later, you also get the benefit of being able to use and swap various transaction managers, without your ORM-related code being affected. As an added benefit, JDBC-related code can fully integrate transactionally with ORM code, in the case of most supported ORM tools. This is useful for handling functionality not amenable to ORM.
• Exception wrapping, as described above. Spring can wrap exceptions from the ORM layer, converting them from proprietary (possibly checked) exceptions, to a set of abstracted runtime exceptions. This allows you to handle most persistence exceptions, which are non-recoverable, only in the appropriate layers, without annoying boilerplate catches/throws, and exception declarations. You can still trap and handle exceptions anywhere you need to. Remember that JDBC exceptions (including DB specific dialects) are also converted to the same hierarchy, meaning that you can perform some operations with JDBC within a consistent programming model.
• To avoid vendor lock-in. ORM solutions have different performance other characterics, and there is no perfect one size fits all solution. Alternatively, you may find that certain functionality is just not suited to an implemention using your ORM tool. Thus it makes sense to decouple your architecture from the tool-specific implementations of your data access object interfaces. If you may ever need to switch to another implementation for reasons of functionality, performance, or any other concerns, using Spring now can make the eventual switch much easier. Spring's abstraction of your ORM tool's Transactions and Exceptions, along with its IoC approach which allow you to easily swap in mapper/DAO objects implementing data-access functionality, make it easy to isolate all ORM-specific code in one area of your application, without sacrificing any of the power of your ORM tool. The PetClinic sample application shipped with Spring demonstrates the portability benefits that Spring offers, through providing variants that use JDBC, Hibernate, TopLink and Apache OJB to implement the persistence layer.
• Ease of testing. Spring's inversion of control approach makes it easy to swap the implementations and locations of resources such as Hibernate session factories, datasources, transaction managers, and mapper object implementations (if needed). This makes it much easier to isolate and test each piece of persistence-related code in isolation.

Above all, Spring facilitates a mix-and-match approach to data access. Despite the claims of some ORM vendors, ORM is not the solution to all problems, although it is a valuable productivity win in many cases. Spring enables a consistent architecture, and transaction strategy, even if you mix and match persistence approaches, even without using JTA.

In cases where ORM is not ideally suited, Spring's simplified JDBC is not the only option: the "mapped statement" approach provided by iBATIS SQL Maps is worth a look. It provides a high level of control over SQL, while still automating the creation of mapped objects from query results. Spring integrates with SQL Maps out of the box. Spring's PetStore sample application illustrates iBATIS integration. Transaction management

Abstracting a data access API is not enough; we also need to consider transaction management. JTA is the obvious solution, but it's a cumbersome API to use directly, and as a result many J2EE developers used to feel that EJB CMT is the only rational option for transaction management. Spring has changed that.

Spring provides its own abstraction for transaction management. Spring uses this to deliver:

• Programmatic transaction management via a callback template analogous to the JdbcTemplate, which is much easier to use than straight JTA
• Declarative transaction management analogous to EJB CMT, but without the need for an EJB container. Actually, as we'll see, Spring's declarative transaction management capability is a semantically compatible superset of EJB CMT, with some unique and important benefits.

Spring's transaction abstraction is unique in that it's not tied to JTA or any other transaction management technology. Spring uses the concept of a transaction strategy that decouples application code from the underlying transaction infrastructure (such as JDBC).

Why should you care about this? Isn't JTA the best answer for all transaction management? If you're writing an application that uses only a single database, you don't need the complexity of JTA. You're not interested in XA transactions or two phase commit. You may not even need a high-end application server that provides these things. But, on the other hand, you don't want to have to rewrite your code should you ever have to work with multiple data sources.

Imagine you decide to avoid the overhead of JTA by using JDBC or Hibernate transactions directly. If you ever need to work with multiple data sources, you'll have to rip out all that transaction management code and replace it with JTA transactions. This isn't very attractive and led most writers on J2EE, including myself, to recommend using global JTA transactions exclusively, effectively ruling out using a simple web container such as Tomcat for transactional applications. Using the Spring transaction abstraction, however, you only have to reconfigure Spring to use a JTA, rather than JDBC or Hibernate, transaction strategy and you're done. This is a configuration change, not a code change. Thus, Spring enables you to write applications that can scale down as well as up.

Next : AOP