My Next Course: Hibernate and JPA

This course has now been released (on Feb 14 2013) – full details here
I’ve been working on projects for the last few months, so it’s been a while since I created a new course.

I’ve agonised what to go for – there are so many vibrant and interesting topics I can cover, but I’ve decided to create a course covering both Hibernate and JPA in full detail.

We have already covered Hibernate in a little detail on our Spring Fundamentals course, and we do some JPA on the JavaEE course, but really we just provide overviews on those courses and we don’t get to a full professional standard.

Hibernate and JPA need a course in their own right, and it’s probably the most asked-for course from our customers, so I’m into the studio on Monday morning to start work.

As always, our video courses take a while to record and edit, we work hard to get them right, so it will be at least 2 months before we’re ready to release. In the meantime, here’s the draft running order – please contact me if there are additional topics that you want to see on the course!

  1. Getting Started
  2. Persisting objects
  3. Relationships in Hibernate/JPA
  4. Bidirectional Relationships
  5. Implementing equals() and hashCode() correctly
  6. Mapping Inheritance Hierarchies
  7. Embedding Objects
  8. Queries using HQL / JPQL
  9. Using the Criteria API
  10. Detached Objects and Merging
  11. Versioning Objects and Locking
  12. Understanding Lazy Initialization
  13. Hibernate/JPA in Web Applications (OpenSessionInView/OpenEntityManagerInView)
  14. Extended Sessions and EntityManagers
  15. Hibernate Caching (and the second level cache)
  16. Hibernate Validators
  17. Introducing Hibernate Search
  18. Auditing with Envers

Accessing Parameters from a Spring AOP 2 Pointcut

I recently had a question from one of our customers, asking how you can access and modify the parameters in Spring AOP 2 – we didn’t refer to this on the course as we concentrated on the most common uses of AOP – so here’s a quick blog post showing how to do this.

If you haven’t used our Spring Fundamentals training course, the full chapter covering AOP is available as a preview below (you can play this at full screen to see the full detail):

Modifying parameters in advice is a very powerful thing thing to do (be careful – powerful means dangerous!), but it can be achieved easily in Spring AOP 2, using the AspectJ syntax.

On the course, we write a performance timing advice class, using Around advice. I’ve taken the annotation based version from the course, and I’ve modified it to take one of the incoming parameters (the customerId) and to change it’s value before passing it on to the target method.

public class ModifyIncomingParameterAdvice
 @Pointcut("execution(* com.virtualpairprogrammers.calls.CallHandlingService.recordCall(..)) && args (customerid, call, actions)")
 public void trapRecordCall(String customerid, Call call, Collection actions) {}
 @Around("trapRecordCall(customerid, call, actions)")
 public Object changeTheIncomingCustomerId(ProceedingJoinPoint method, String customerid, Call call, Collection actions) throws Throwable
  System.out.println("Asked to record a call for customer id " + customerid);
  // run the target code - but with a different customer id!
  String newCustomerId = customerid + "NEW";
  // we can pass parameters as an object array - you must get the correct number of 
  // parameters as the target is expecting, or you get a runtime exception.
  Object returnValue = method.proceed(new Object[] {newCustomerId, call, actions});
  return returnValue;

Notice the use of the args() in the pointcut. This is the important part of this technique. It is applying the pointcut only to invocations of methods called recordCall that have exactly three incoming parameters. And these three parameters are given names which we can use as parameters to the Around advice.

If you want to use the XML form of AOP (I prefer XML for AOP in Spring), then you would just change the pointcut in your Spring XML – a rough example follows:


Notice that I had to escape the ampersands (&) in the pointcut, as you will get an XML error otherwise.

Now, this is a made up and probably useless example, but I hope you can see the power of this. I guess that most projects will very rarely want to use this technique, but I’d be very interested if you’ve used this on your real world projects – do tell me if you have some examples.

Importing a Project into Eclipse

Several viewers of our Spring MVC course have reported problems in importing the project code that is supplied with the course.

I should really have shown the steps on the videos as it can be quite awkward in Eclipse. There are several different ways of achieving this, but these steps work best for me:

1) Your “Practicals and Code” download contains a “Starting Workspace” folder. Open this as a workspace in Eclipse.

2) Once Eclipse is opened, you will notice that the left hand panel (Package Explorer) is blank.

3) Select “File -> New Java Project”.

4) The workspace contains a folder called “MVC Project”. This is the project folder. On the New Project wizard, type in exactly the same name – “MVC Project”. On typing the final character, you will see that several options are grayed out, and a message is displayed indicating the a new project based on the existing source is going to be created.

5) Click finish, and a full project should now appear in the left hand pane.

Using Sessions in Spring-MVC (including “scoped-proxies”)

On the Spring-MVC video training course, I described three different approaches to handling sessions in Spring.

On the video, I mention that there is also a fourth way, but since the course was getting a bit long I said that I would cover this in a blog post, and here it is.

Thankyou to Bob Casazza for reminding me to do this.

First, a recap of the three approaches described on the video:

1: Use HttpSession directly.

With this approach, you declare HttpSession as a parameter to your controller method. The example on the course looks like this:

public ModelAndView addToCart(@RequestParam("id") int id, HttpSession session)
   ShoppingCart cart = (ShoppingCart)session.getAttribute("cart");
   // etc, continue with the cart

Pros: it’s simple, very much like you would do it in older Spring-MVC and other less capable frameworks.

Cons: it’s messy, exposes your clean controller to the Servlet API and needs null checking after you’ve called getAttribute. Unit testing of your controller is now much harder to do (you need to Mock the HttpSession object).

I don’t like this approach, I would avoid it unless necessary (later in the post, I’ll explain when I would use it).

2: Scope the Controller

Make your controller session scoped. You can then simply instantiate the object you want to store in session scope as a member variable of the controller…

public class CartManagementController
   private ShoppingCart cart = new ShoppingCart();

   public ModelAndView addToCart(@RequestParam("id") int id)
      // now just use the cart

Pros: A very clean controller, very unit testable.

Cons: A new controller is created for each session, the controller object must be stored in HttpSession. This could bloat the session and in particular could mean replication problems on a large scale system. (Replication: where your web application is hosted on multiple servers. Then the session has to be copied from one server to another. Whilst this is automatic, big sessions cause serious performance problems)

3: Scope the Objects in the Session

This is a narrowing of the session scope, and we session scope just the object we want to store in the session.

public class ShoppingCart
   // just a plain java class - member variables and methods as usual

Note that the class is now a Spring Bean.

Then, we inject instances of the class into the controller:

public class CartManagementController
   private ShoppingCart cart;

   public ModelAndView addToCart(@RequestParam("id") int id)
      // now just use the cart

So, for each request, Spring creates an instance of the controller and then finds the shopping cart from the session.

Crucually, the controller in this approach MUST be request scoped. The default is for Spring to create a global singleton instance of the controller, and this would not work as a singleton is shared by all requests (you can’t injection session scoped objects into singleton scoped objects anyway).

Pros: Clean testable controller as in approach two, with the added benefit of the session now only holds the relevant session data.

Cons: A new instance of the controller is created for each request. This is fine if the controller is “small”, but if it is expensive to create (ie the constructor is slow for some reason), scalability would be a problem. Also, this approach is harder to understand because of the request scoped controller.

Ok, so they’re the three approaches on the course. The problem is they all have drawbacks. I personally almost always use approach 3 where possible, but if I have a “heavy weight” controller, I’d consider using approach 1.

But the fourth approach removes all of the downsides of the previous. The only “con” of this approach is that it is much more complicated. It relies on Spring’s best friend: proxies…

4: Use a <aop:scoped-proxy/>

This is covered in full in the Spring Reference manual (at the time of writing, at

The general idea of this approach is that you declare your session data as a regular spring bean, with a special tag applied to it (<scoped-proxy>). Your controller will remain a regaular Spring bean, as singleton scope.

With the scoped-proxy tag, your controller looks like it is holding a reference to the session data, but it is actually holding a reference to a proxy which Spring has generated at run time. This proxy’s responsibility is to find a session each time it is accessed.

If this is a bit complicated, you might need to check out our AOP session in the Spring Fundamentals video. Or, you can just copy what’s here:

Sadly, they haven’t created an annotation for scoped-proxy, so your session data (the shopping cart) has to be declared in old-school XML. You add this to your Spring wiring (eg Dispatcher-servlet.xml on the course):

<beans xmlns=""

   <!-- an HTTP Session-scoped bean exposed as a proxy -->
   <bean id="shoppingCart" class="com.virtualpairprogrammers.ShoppingCart" scope="session">
      <!-- this next element effects the proxying of the surrounding bean -->

Now, your controller looks very simple:

public class CartManagementController
   private ShoppingCart cart;

   public ModelAndView addToCart(@RequestParam("id") int id)
      // now just use the cart

Pros: unit testable and clean as before, only session data is stored in the HttpSession, and the controller is a single-instance global singleton, so no issues with performance of creating them.

Cons: it’s much harder to understand (I’ve taken hours over this post!) and you have to fall back to old fashioned XML wiring.


The “fourth approach” is probably the most elegant in that it solves all of the technical problems identified earlier. But really, in most situations, approach 3 will be just fine. I have never felt the need to use this fourth approach, it seems like a really heavy solution to the session “problem”.

In real life, I’ve always been happy to use approach 3, and when I’m worried about performance (in the rare case where I’m doing heavy work in the constructor), I’ll use approach 1 instead.

I hope no-one minds me omitting approach four from the course, I felt that we had more than enough information on sessions – but I’m glad I’ve been able to cover it here.

A Fix to Our Spring-MVC Course

Just a quick blog post to alert that there is an error in one of the config files in the Spring-MVC course. I’m uploading a fixed version now, so if you’re a user of the course, please download the new “Practicals and Code” folder, or follow these instructions:

If you start your project from the “Starting Code” folder, our web.xml contains the following:

   <!--  we've already configured Spring-MVC for you - nothing to do here! -->         

However, our Spring XML config file is called “Dispatcher-servlet.xml”.

By default, Spring finds it’s config file in a web app by taking the servlet name and appending “-servlet.xml” to the end – it then looks for a matching file in /WEB-INF.

If you downloaded the course before the date of this post, please rename the servlet name to Dispatcher (it appears twice in web.xml).

So, your web.xml file should be (in full):

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns=""
    <!--  we've already configured Spring-MVC for you - nothing to do here! -->         


Many apologies for the inconvenience this has caused – it was entirely my fault and happened because I changed my naming convention between chapters.

Thanks to David Wubshet and Benjamin Quarless amongst others for flagging up this problem.

Integrating Spring MVC and a “Real” Database

On the Spring MVC and WebFlow video training course, we build a system from scratch based around a book store. To keep things focussed on the web tier, we use a mock implementation of a service class.

Therefore, we can run the system up without worrying about setting up a database, getting the tables set up etc.

However, I’ve had a few requests from people who are stuck on “upgrading” their Spring MVC project that uses the Mock. They want to talk to a back end database but for some reason it isn’t working.

The best way to work is to start from your Spring-MVC project, and make sure that is working. As on the course, you’ll probably have a Dispatcher-servlet.xml file with the web-tier beans, and a separate application.xml containing the “middle-tier” beans.

Now write a production version of your service class, in the same style as on the fundamentals course (for example, service class calls a dao which uses a Spring template to read/write to the db).

As all of the above is covered in both courses, it’s just a case of integrating your knowledge.

There are a couple of steps you might need to follow however:

1: Add in missing Jar files

Add in any JAR files that you need for your data access strategy. I used Hibernate 3 (the old XML mapping style, not annotations), and I added:


If you’re using Hibernate with Annotations, or MyBatis or whatever, your dependencies will be different. I simply borrowed these JARs from the project I created on the Spring Fundamentals course.

Step 2: Ensure your mapping files are copied across (Hibernate XML only)

Now for an annoying complication: I’m using the old fashioned but still usable XML mapping approach to Hibernate. I have a file called Book.hbm.xml in my package “com.virtualpairprogrammers.domain”.

However, this file is not being picked up by the build script we used on the Spring MVC course. When Eclipse compiles, it copies any non-Java files from the /src folder structure, across to the corresponding folder under /bin.

The ant compile task does NOT do this, however. So I need to manually add this step into my build.xml.

<!-- ensure hibernate XML files are also moved in the compilation -->
<copy todir="${bin}">
   <fileset dir="${src}">
      <include name="**/*.hbm.xml"/>

Note: this is added inside the compile target.

I’ve uploaded a full sample project to These sample files will only be available for a short period, so grab them while you can.

So What’s Wrong with Checked Exceptions?

In part one of this blog post on Checked Exceptions, I defended them. They have a very valuable place in Java’s toolbox, and those who argue for their removal are missing the point of them.

The trouble is, they’re overused. In the early days of Java, everyone assumed that Checked Exceptions were the “right” things to use in all circumstances.

But when you throw a checked exception, you are forcing the caller to handle the problem. But often, problems can’t be possibly be handled by program code. The number one example of this is when writing JDBC (data access) code:

   String sql = "INSERT BOOK (bookID, ISBN, title, author, price) VALUES (?,?,?,?,?)";

   PreparedStatement stmt = con.prepareStatement(sql);

   // bind the parameters - omitted
catch (SQLException e)

(This is just a fragment for illustration – don’t use this in any real code. I’ve omitted the closing of the connections – don’t even get me started on that nightmare).

Now, seriously, what code can you possibly put in this catch block? Firstly, there are hundreds of things that could go wrong here:

1) Network connection to database down (a squirrel has eaten a cable somewhere)
2) No access to database allowed (bad credentials)
3) SQL statement grammar incorrect – [in fact – it IS! I deliberately made a typo in the SQL]
4) Datatypes of data wrong
5) Our DBA has gone mad/got drunk and dropped the table for a joke
6) Constraint violation

I could go on. But the point is:

None of these problems can be handled in the catch block. How can your code possibly fix the SQL error in my hardcoded string?

So what CAN we do? Well, if we continue to use checked exceptions only, then we have to throw the exception to the caller. But think about it – how can our caller (whatever that is) deal with any of the six problems above? Almost certainly, they can’t so they will re-throw it too. And their caller will have to rethrow it, and so on until it reaches probably the top level of our call stack.

The worst aspect of this is that many Java programmers don’t get this – they think because they’ve got an exception, they MUST deal with it there and then (they forget it can be rethrown). Which is why you’ll often see this disgusting code in production:

   // SQL and JDBC as above
catch (SQLException e)

Which translates as “hide the problem in a log file somewhere and then let’s carry on as if all was well”.

Probably the best you can do is to manually convert it into an unchcked exception. Since JDK1.4, you can wrap exceptions so that you don’t lose the detail of the original cause:

   // SQL and JDBC as above
catch (SQLException e)
   throw new RuntimeException(e);
   // or you you create your own runtime exception like DataAccessException

SQLException should have been made an *Unchecked* Exception in the first place. This would have meant that we could let the problem rise up the stack until it reaches an appropriate level where we should handle it.

If you’re in the lucky position of writing web applications, then you need never catch the unchecked exception – because web applications run in a container like Tomcat, effectively the Tomcat code is the “top level” of your app – you simply configure Tomcat to catch all unhandled exceptions, and to report them to the user and the system admin.

This is why the Spring Framework supplies a wrapper layer around JDBC, which automatically catches the checked exceptions for you, and it throws them to your code as unchecked exceptions. We talk about this in detail on the Spring Framework Online Course

When to use Checked or Unchecked?

Checked and Unchecked Exceptions are two very different tools. In fact, I suspect that the confusion about them arises because they’ve been given very similar names (even worse, the words Checked and Unchecked don’t even appear in the API). The designers of Java should have given them clear distinction in the API.[1]

  • Checked exceptions are for situations where you know your method has reached a condition which means the end goal of the method can’t be achieved, but somewhere in the call chain we except the problem can be dealt with.
  • Unchecked exceptions are for situations where something has gone wrong, but due to the nature of the problem, it’s likely that the problem can’t be handled (or would be best caught with a global error handler). Perhaps a configuration problem (eg a vital config file is missing) or an environmental problem (eg a database table has disappeared), or maybe even a problem within the code (eg a hardcoded SQL statement is wrong).

The point is, they are different tools and both have their strengths and weaknesses. Java is unique in having Checked Exceptions, and it would be a shame to see them removed from a future version of Java (as some people want).

[1] The inheritance hierarchy is broken also. RuntimeException extends Exception, which technically means that RuntimeException is a special kind of Exception. When it really, really isn’t (perhaps you could argue that Exception is a special kind of RuntimeException). This means that whenever you catch raw “Exception”, you are also catching RuntimeExceptions, even those such as NullPointerException, which is definitely something you don’t want to do.

In Defence of Checked Exceptions

I’m often asked about exceptions in Java, and whether Unchecked Exceptions are “better” than Checked Exceptions.

This is probably because in our Spring Framework online course, I spend a while talking about Spring’s Data Access Exception strategy, where checked exceptions are converted to unchecked ones.

See also blogs like Bruce Eckel’s , which is fairly damning about Checked Exceptions.

As some of you may not be familiar with the difference between Checked and Unchecked exceptions, let’s look at the difference between them.

Checked Exceptions

A checked exception is one that extends the java.lang.Exception class, and the rule is:

“Any call to a method that might throw a checked exception MUST handle the exception”.

By “handle”, I mean it must either

a) Handle the problem in a try…catch block
b) Throw the exception to the next level up

This means, that unless you’re cheating by swallowing the exception somewhere (this means an empty catch block), or you’re throwing exceptions from main(), then checked exceptions are guaranteed to be handled by your code, somewhere in the call chain.

Unchecked Exceptions
These are exceptions that don’t need a try…catch block anywhere, although you can optionally try…catch them if you want to.

To define an unchecked exception, your exception definition will extend java.lang.RuntimeException.

The risk of using Unchecked Exceptions is that they might never get caught. If they don’t, your program crashes. I’ll talk about why unchecked exceptions are useful in the second part of this post.

Using Checked Exceptions

Surveying the Java blogging world (eg Bruce’s post above), it’s fair to say that Checked Exceptions have a terrible, terrible reputation and are hated by a large proportion of Java programmers. Whilst I don’t blame them, this is unfair. Checked Exceptions have a lot of value but they are overused.

On my live Java course, I use a simple example of a checked exception…

public class NoOrdersAvailableException extends Exception
   // nothing important to add

Which is thrown from a method something like the following:

public class OrdersQueue
   public Order getNextOrderInQueue() throws NoOrdersAvailableException
      // do a database query to find the order
      // omitted

      if (nextOrder == null) throw new NoOrdersAvailableException();
      return nextOrder;

Why does the getNextOrderInQueue() method need to throw an exception? Because it has reached a condition where there are no orders available, and therefore it cannot fulfil the task it said it was going to do. I think of the signature of the method as being a contract:

public Order getNextOrderInQueue()

Meaning, “if you call this method, with no parameters, then the next order in the queue will be returned”.

Notice that we cannot handle the problem in this method. There are no orders in the queue, and the only solution is for the user interface to report this back to the user. But this is not a user interface class, so the caller needs to handle the problem.

And there’s the key: the caller NEEDS to handle this problem, and if the caller somehow misses the problem, we would have a serious problem (possibly silent failure).

Here’s the caller:

public class UserInterface
   public void showNextOrder()
         Order requiredOrder = ordersQueue.getNextOrderInQueue();
         // now add the order to the user interface screen
      catch (NoOrdersAvaialableException e)
         // show an information message to the user

I admit the code is long winded, and typing in try..catch blocks is never fun. But it is at least readable, I can work out exactly what is happening from this code with little prior knowledge (this is why naming exceptions well is a crucial skill).

Without checked exceptions, we would have to handle nulls, or create blank Order objects, or have some kind of pre-check such as “isOrderReady”, which would be prone to race conditions (you get back true from isOrderReady, but by the time you’ve called getNextOrderInQueue(), some other process has stolen your order!).

So checked exceptions have a very valuable place in helping you to write readable, clean and safer code. But in my next blog post, I’ll describe where Checked Exceptions should NOT be used.

Spring MVC and WebFlow – Released!

Well, it took a while but I’m relieved that the course is now out. Full details available at the site

And you can preview the opening chapter over at YouTube

I’ll be uploading some more previews of the more interesting chapters later this week, and for those of you needing the DVD edition, it will be available on Amazon as soon as we get the stock to them.

One of the reasons for the delay was the sheer amount of information in Spring-MVC. Despite a long running time (8 hours), there are still one or two topics that I wish had made the final cut, so keep an eye out for a few blog posts over the next few weeks that will fill in some gaps.

Another reason was the last minute decision to add WebFlow – I’m very glad I did this because although I love WebFlow, there’s not that much out there to help beginners.

I hope you like the course!

Changes to the Spring-MVC Course – now with added WebFlow!

We’re getting closer to releasing the Spring-MVC course and as we reach the end it’s becoming clear that some juggling is needed to the back end of the course.

Many people have contacted me to ask about Spring WebFlow, and whether we’ll be doing a course on it. I’d always planned to do a separate standalone course on this topic, but on reflection I’ve decided it would fit more naturally as a chapter on the Spring-MVC course itself.

The revised running order is now:

1: Introduction
2: An overview of MVC
3: First steps in Spring MVC
4: Mapping Parameters, Accessing Sessions
5: Internationalization (i18n)
6: Form Handling and Validation
7: Validation and JSR-303
8: Alternative views and Ajax
9: Spring WebFlow – the Basics
10: Going further with WebFlow

The chapter on Post-Redirect-Get was too small to stand on it’s own and is now part of the form handling chapter.

I think this outline is a bit tighter and more focussed, and with WebFlow included, will be much better value.

It does, however, mean a slight delay to allow time for scripting and recording of the more advanced material, but not a big one, we’re now on for Friday 6 August.