Saturday, August 23, 2014

How to Inject Objects Into Spring MVC Controller Using HandlerMethodArgumentResolver

This post shows how to implement HandlerMethodArgumentResolver in other to resolve and inject objects into Spring MVC controllers, but before we get to the actual implementation procedure, a little trivial overview of Spring MVC would be good.

Spring MVC is designed around the Front Controller Pattern which it uses to implement the Model View Controller pattern.

Since you are reading this post, I can rightly assume you already use Spring MVC and you know how it generally works: You register the DispatcherServlet -Spring MVC's Front Controller, write your controller class and map requests to controller methods using @RequestMapping, then put the necessary configuration in place which would enable Spring to pick the written controller class and have it as a spring managed bean.

A trivial controller class may look like this:

package com.springapp.mvc;

import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.RequestMapping;

public class HelloController {

    public String doGreeting(Model model) {
        model.addAttribute("greet", "Hello World");
        return "helloView";

So when a request hits /index, doGreeting(...) method is invoked with an object of Model (the M in MVC) passed into it, which is populated with the greet property which can then be accessed in whatever view technology in used. The view is located using the "helloView" string returned by the controller.

Tuesday, August 05, 2014

Configuring Maven to Fetch Artifacts from Multiple Repositories

It is quite common to have a situation where a project needs to source for artifacts from more than one source. This post quickly explain 3 different ways to achieve this.

Repositories settings in pom.xml

In pom.xml, you have the <repositories/> tag which can be used to specify the repositories a project should search and download artifacts from. For example:

Sunday, July 20, 2014

Common Date-Time Operations In Java - Formatting and Parsing Date-Time

In Date and Time With Java, a general overview of date/time related API was given. This post walks through formatting and Parsing Date-Time in Java.

Parsing and Formatting Date and Time.

What is the difference between December, 04, 1984 and 12/04/1984, and 04/Dec/1984 and ... or difference between 13:00hr and 1PM and...

Formating. They all represent the same date and time but are formatted differently.

Formatting date/time values as string, and parsing date/time values expressed in string into objects, are one of the common tasks when dealing with date/time. 

Formatting allows you to take a Java object that represents date or time and convert it into a string represention using a predefined formatting.

Conversely, with parsing, you take date or time values expressed as strings and have it converted it into valid Java date or time objects.

We quickly go over how to accomplish these tasks:

Saturday, July 19, 2014

Date And Time With Java

How do you deal with dates and time in Java and perform common operations like finding difference between two dates or translate dates into a particular string formats?

This post seeks to provide an answer to those questions.

I would start off by giving a brief description of the available date related classes and packages you might encounter on the Java platform and then do follow up posts exploring some of the common date/time operations like how to format date-time, dealing with time zones and locale, finding differences between dates/times etc.

Sunday, July 06, 2014

Hooking Into Container and Bean Life Cycle in Spring.

"What is the difference between BeanFactoryPostProcessor and BeanPostProcesser" This, said one of my colleagues, was part of his interview question, a question to which he promptly replied: "I don't know".

Once you pass the stage of actually getting Spring to work, passing the configuration huddle, in no time, the next couple of things you would probably run into would involve using or hooking into the various life-cycles in Spring and you start seeing things like BeanFactoryPostProcessor, BeanPostProcessor, DisposableBean, InitialzingBean, PostConstruct etc, which all seems to be callbacks mechanism that enables you plug in, somehow, into all the magic going on in Spring.

...And probably just like me, it all starts feeling like too much to grasp...Also, sooner or later, you run into the *Aware sets of interfaces.

Dang! What are all these, How do they fit into the picture? I just want to write a web application, why do I have to grapple with all these what not?

I initially had all these concepts swirling all about without having any concrete mental model to attach them to or a good understanding of what actually is going on. I knew about the @PostConstruct annotation and maybe what it does, I also have come across various *Post Processors and maybe the IntializingBean interface a couple of times, but actually grokking and understanding where they fit did not happen until after spending some time working with other parts of Spring which allowed for a broader view of what is going, helping create some sort of mental model.

Monday, June 09, 2014

How to Autowire a Bean That Requires Constructor Argument In Spring

Spring allows you to inject a managed object (bean) as a dependency into another object via the @Autowired annotation.

For example, if I have a UserService that has a dependency on UserRepository, I can have the UserRepository injected using @Autowired annotation like this:

UserRepository Class...
class UserRepository {
UserRepository () {}

UserService Class...
class UserService {

private UserRepository userRepository;

UserService () {}


This is done using Field Injection. The same thing can be accomplied using Setter Injection:

class UserService {

private UserRepository userRepository;

UserService () {}

@Autowired // Using setter injection
public void setUserRepository(
UserRepository userRepository) {
this.userRepository = userRepository


or via Constructor Injection:

class UserService {

private UserRepository userRepository;

@Autowired // Using constructor Injection
UserService (UserRepository userRepository) {
this.userRepository = userRepository


There are different opinions on which method is "the right way" but since this post is not about that debate. I would point you to this post instead: Why I changed My Mind About Field Injection

Which ever method you choose to use, you are essentially doing the same thing: instructing Spring to supply an object's dependency by using the @Autowired annotation.

But what happens when the Object you want injected in has a constructor that requires an argument?

Making Aliases Permanent

Aliases provides you with short cuts to commands or group of commands.

..For example, instead of always having to type ls -la to get the long listing format of a directory's content, you can set up a short form, say ll and type that instead. You do this via aliases by typing in an open terminal this:

alias ll='ls -la'

It would set up an alias of ll that equates to 'ls -la'. As you see the format of setting up an alias is:

alias alias_name="command"

The only issue with this, is that the alias is lost once you end the terminal session. i.e. once you close the terminal. To make the aliase permanent you need to add it in a place where it gets loaded and available at the start of a terminal session.

The most appropiate place to put the aliases in other to make it permanent is in an hidden file called .bashrc in the user's home directory. Or better still, put it in a file usually named as .bash_alaises and have it refereced from .bashrc

This is straight forward.

with vim ~/.bashrc

and you add the aliases in the .bashrc file as shown above. The other, more prefered way is to create another file, usually named .bash_aliases and put your aliases inside instead.

The reason this works is due to the presence of a code section in .bashrc that loads the content of the .bash_alaises.

The portion of the .bashrc looks like this:

If you do not have this piece of code, feel free to add it.

All this has been easy, straight forward and clear enough. The confusing part to all this, especially if you are new to linux, is the seemingly plethora of other files you can put your aliases in and all mysteriously seem to get the job done.

If you do a google search you may find results that points to other files where you can define aliases. /etc/profile, ~/.profile, ~/.bash_login, .bash_profile

The reason these all seems to work is because they are all special kinds of files that have their contents sourced by the shell at different point in time. Some are sourced at login, some are sourced when the shell is invoked interactively.

To really understand how they all fit, lets go over some basic stuff here: