MyBatis - MyBatis-Spring | Transactions

MyBatis - MyBatis-Spring | Transactions: "One of the primary reasons for using MyBatis-Spring is that it allows MyBatis to participate in Spring transactions. Rather than create a new transaction manager specific to MyBatis, MyBatis-Spring leverages the existing DataSourceTransactionManager in Spring."

'via Blog this'

Aspect - add interfaces

java.lang.ClassCastException: "That's true - your bean is proxied to wrap it with transaction support (as you have requested in the configuration). And proxies used by Spring proxying by default (JDK proxies) proxy interfaces implemented by class, not class itself. If you absolutely need to you may instruct Spring to use CGLIB-proxying by setting proxy-target-class=true (see Spring Reference for details, but it is not advisable. Progamming to interfaces is a way to follow."

'via Blog this'

Chapter 9. Transaction management

Chapter 9. Transaction management: "The Spring Framework provides a consistent abstraction for transaction management that delivers the following benefits:

Provides a consistent programming model across different transaction APIs such as JTA, JDBC, Hibernate, JPA, and JDO.

Supports declarative transaction management.

Provides a simpler API for programmatic transaction management than a number of complex transaction APIs such as JTA.

Integrates very well with Spring's various data access abstractions."

'via Blog this'

Chapter 6. Aspect Oriented Programming with Spring

Chapter 6. Aspect Oriented Programming with Spring: "Aspect-Oriented Programming (AOP) complements Object-Oriented Programming (OOP) by providing another way of thinking about program structure. The key unit of modularity in OOP is the class, whereas in AOP the unit of modularity is the aspect. Aspects enable the modularization of concerns such as transaction management that cut across multiple types and objects. (Such concerns are often termed crosscutting concerns in AOP literature.)"

'via Blog this'

Chapter 5. Implementing Database Persistence

Chapter 5. Implementing Database Persistence: "This is Part 5 of a step-by-step account of how to develop a web application from scratch using the Spring Framework. In Part 1 we configured the environment and set up a basic application. In Part 2 we refined the application that we will build upon. Part 3 added all the business logic and unit tests and Part 4 developed the web interface. It is now time to introduce database persistence. We saw in the earlier parts how we loaded some business objects using bean definitions in a configuration file. It is obvious that this would never work in real life – whenever we re-start the server we are back to the original prices. We need to add code to actually persist these changes to a database."

'via Blog this'

Spring MVC 3.0 with STS Tutorial – Part I | duckranger.com

Spring MVC 3.0 with STS Tutorial – Part I | duckranger.com: "Generally, a controller method should not return just a String. It should actually return a ModelAndView object, which contains both the model we discussed earlier, and the view to resolve (or rather – a way to find the view).
However, as you can see, in our generated Spring-MVC project, the controller method returns only a String, which contains the view name. This is alright, as long as we tell the container how it should resolve the view and serve the correct page to the client.

The InternalResourceViewResolver does exactly that. It is configured as a bean, and since it is the only view resolver configured, the Spring container knows that this is the one it should use. In essence, the InternalResourceViewResolver receives the result of the controller method (the String returned) – and is then in charge of mapping this result to an actual view."

'via Blog this'

Green Beans: Getting Started with Spring MVC | SpringSource Team Blog

Green Beans: Getting Started with Spring MVC | SpringSource Team Blog: "Spring MVC includes most of the same basic concepts as other so-called web MVC frameworks. Incoming requests enter the framework via a Front Controller. In the case of Spring MVC, this is an actual Java Servlet called DispatcherServlet. Think of DispatcherServlet as the gatekeeper. It doesn't perform any real web or business logic, but rather delegates to POJOs called Controllers where the real work is done (either in whole or via the back-end). When the work has been done, it's the responsibility of Views to produce the output in the proper format (whether that's a JSP page, Velocity template, or JSON response). Strategies are used to decide which Controller (and which method(s) inside that Controller) handles the request, and which View renders the response."

'via Blog this'