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'
Wednesday, 18 April 2012
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'
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'
'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'
'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'
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'
'via Blog this'
Subscribe to:
Posts (Atom)