The Best Comments of September 2015

I think that the best part of writing a blog is to get comments from my readers.

Because I have learned a lot from my readers, I want to “reward” the best comments, help you to learn new things, and (hopefully) encourage people to leave more comments.

The rules are simple:

  • I select X best comments that were left on my blog during the previous month.
  • I link to these comments and explain why I chose them.
  • If the author of the selected comment has a blog, I add a link to her/his blog as well.

Enough with chit chat. The six best comments of August 2015 are (in chronological order):

The Six Best Comments of September 2015

Tauseef asked why one of my query methods wasn't working as expected (it returned a Todo object instead of a String object). I selected this comment on this list because of two reasons:

  1. It proves that I make mistakes.
  2. It helped me to realize that Spring Data JPA might support projections in the future.

If you want get information about this, check out my answer.

Hamsa asked why his/her unit test is failing. This comment deserves to be on this list because Hamsa gave me a lot of background information. This meant that I was able to solve his/her problem without asking any additional questions. Also, if you want to know how you can write assertions for Spring MVC flash attributes, you should check out my answer.

Ketki asked two questions:

  1. Which configuration method is preferable, Java based or XML
  2. Do I need to declare the PersistenceAnnotationBeanPostProcessor bean?

This comment deserves to be on this list because of the second question. It reminds us that we shouldn't copy our configuration classes (or XML files) from our old projects without reviewing them. Naturally, I answered to the first question as well.

Matt asked why the cannot run the example application of my Spring Data Solr tutorial. I selected this comment because my answer is useful to other people who are trying to run it with Java 8.

Derek pointed out that I should clean the security context of my scheduled job inside a finally block. This comment deserves to be on this list because Derek found a bug from my example and reported it to me.

Michael P claimed that it is not be wise to write unit tests with Spring MVC Test because you end up testing the "features" provided by Spring MVC. I selected this comment because Michael P has a point, but I will continue writing unit tests with Spring MVC Test.

0 comments… add one

Leave a Reply