Benefits of @Repository annotation ( and Root of the hierarchy of data access exceptions ) in Spring Framework

There are a bunch of stereotype annotations in Spring. Most of time differences are not exactly known. For example we use @Component annotation for DAO classes for a long time in our company and it works. But we didn't know benefits of @Repository annotation till now.

If we want to summarize it, we can say that "By using @Repository annotation in DAO classes, different kinds of exceptions that belongs to many kinds of data access technologies will be transparently converted to standard DataAccessException classes of Spring"

Let's think about real life. In an enterprise project we may need more than one data access technologies like JPA, Hibernate or even JDBC. Each of them has its own benefits but all has their own exceptions. In that case exception handling can easily turns into a code hell.

Root of the hierarchy of data access exceptions adress this issue and gives us a bunch of classes that we can handle easily in a standart way. Thus we have a strong abstraction layer for data access exceptions and we can handle each exception case as we want.

Schema of data access exceptions classes is below;

[1] Root of the hierarchy of data access exceptions discussed in Expert One-On-One J2EE Design and Development. Please see Chapter 9 of this book for detailed discussion of the motivation for this package.

ExtJs calls url with OPTIONS method problem.

When I'm trying to create a Restful grid with ExtJs it calls url with OPTIONS method . I couldn't despite I explicityly define method as GET. After two days finally I find the solution ScriptTagProxy.

You can read explanation from ExtJs documentation;

"An implementation of Ext.data.DataProxy that reads a data object from a URL which may be in a domain other than the originating domain of the running page.

Note that if you are retrieving data from a page that is in a domain that is NOT the same as the originating domain of the running page, you must use this class, rather than HttpProxy."

But now there is another problem because documentation also says that;

The content passed back from a server resource requested by a ScriptTagProxy is executable JavaScript source code that is used as the source inside a script tag. In order for the browser to process the returned data, the server must wrap the data object with a call to a callback function, the name of which is passed as a parameter by the ScriptTagProxy.

 You have to send your data inside a  script. The name of the script is sending in the callback parameter of the URI like http://foo.com/bar?callback=methodName .