Social Icons

twitterfacebookgoogle pluslinkedinrss feedemail

Tuesday, December 13, 2011

Using Spring and MyBatis for non-POJO Data Retrieval

This post will be part one of two dealing with data retrieval in Spring with MyBatis. This post in particular will discuss data retrieval whereby you have a situation where you do not have a DB Schema-to-POJO relationship, e.g. in a properties or settings table.

I won't get into how to set up a Spring datasource bean and will assume you already have one in your Spring config file.  In your Spring config file, per http://code.google.com/p/mybatis/wiki/Spring, add a new bean to configure your SqlSessionFactory using the datasource you defined above.

Next, the mybatis-spring library allows us to wire up things automagically (without declaring our mappers in XML) with the following:

<!-- scan for mappers and let them be autowired -->
<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
  <property name="basePackage" value="com.foo.persistence"/>
</bean>

This tells the scanner to recursively scan the com.foo.persistence package and create Spring beans for each mapper it finds. If you're using only one datasource, you don't even need to wire that in as the scanner will take care of this for you.

Next, you'll need to create a mapper class like so:

package com.foo.persistence;

import org.apache.ibatis.annotations.Insert;
import org.apache.ibatis.annotations.Param;
import org.apache.ibatis.annotations.Select;

public interface SettingsMapperInterface {

  @Select("SELECT value FROM settings WHERE name = #{name}")
  String getValue(@Param("name") String name);

  @Insert("INSERT INTO settings VALUES(#{name}, #{value})")
  void setValue(@Param("name") String name,
                @Param("value") String value);
}

This defines two methods, one for getting a value from our settings table and one for inserting a value into our settings table. Note that the package name matches what we defined as the "basePackage" for the scanner bean above. Remember that this is recursive so we could have put this in package "com.foo.persistence.settings" and it would still work. In fact, for larger systems, organizing your mappers by package is probably not a bad idea.

Next, let's define a Spring service that is responsible for interacting with the database. This is our DAO layer or business layer. We don't want to pollute our controller with business logic and vice versa - i.e., we don't want to put any UI or action logic in our business layer. Here's what the service class looks like:

package com.foo.service;

import com.foo.persistence.SettingsMapperInterface;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class SettingService {

  public String getValue(String name) {
    return this.settingsMapper.getValue(name);
  }

  @Transactional
  public void setValue(String name, String value) {
    this.settingsMapper.setValue(name, value);
  }

  @Autowired
  private SettingsMapperInterface settingsMapper;
}

Recall how we said above that the scanner automatically creates Spring beans for each of our mappers. Here, you can see we are autowiring this bean into our service class. One note on IDEs, my IntelliJ instance complains about there not being a bean defined with the SettingsMapperInterface type. This is annoying, but it's not a problem. At the time of this writing, I could not find any MyBatis support for IntelliJ.

Finally, we can autowire our service up like any other bean as follows:

package com.foo.controller;

import com.foo.service.SettingService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@Controller
public class SettingController {

  @RequestMapping(value = "/foo/getSetting",
                  method = RequestMethod.GET)
  public void getSetting(HttpServletRequest request,
                         HttpServletResponse response) {

    String settingName = request.getParameter("settingName");
    String settingValue = this.settingService.getValue(settingName);

    // do something with "settingValue"
  }

  @Autowired
  private SettingService settingService;
}

Here, we pull the name of the setting we want to retrieve off of the request as a parameter (called "settingName") and pass it to the service method for retrieving a setting's value from the database. We can then take this value and do anything we want with it.

Monday, December 5, 2011

Reading Spring Controller and RequestMapping Definitions

My current, major task at work is to bring two existing web applications into one utilizing a single-signon mechanism and overhaul the UI based on my recommendations previously made.  Part of the background architecture work involved in allowing the creation of a menu structure that would ultimately be utilized to create a similar structure in the UI.

I wanted to use JAXB to unmarshall my menu XML into Java objects but I suspect the complex nature of the XML schema and some limitations of the JAXB framework combined with my lack of a complete understanding of JAXB hindered this process to such a degree that I had to stop due to the time I was spending on it.  So, instead of getting the created objects "for free" I had to resort to writing my own SAX Parser event handler to build up the menu structure in Java land.  I had tried a DOM-based approach first, but the recursive nature of the elements made me cringe a bit while writing the code and if you ever have the thought of "there's got to be an easier way to do this" while writing code, your best bet is to just flat out stop what you are doing and take some time to thoroughly think things through before spending any more time on the task.

The event handler also built up the menu item URI paths using attributes on the hierarchical menu structure in the menu XML.  This gave the menu item actions (arbitrary) name-spacing.  I say arbitrary because when using Spring MVC with only one DispatcherServlet, the URI paths are essentially meaningless.

One other thing I wanted to ensure was that we would never have a dangling menu item - that is a menu item defined (and in the UI) but not actually tied back to a Spring Controller method.  So, I created a unit test that loads my menu XML, pulls a list of all the RequestMapping annotated methods, and confirms that every menu item ties back to a server-side method.

Here's the code:

  Map<String, Object> controllers =
    this.ctx.getBeansWithAnnotation(Controller.class);
  for(Map.Entry<String, Object> entry : controllers.entrySet()) {

    Class controllerClass = entry.getValue().getClass();
    for(Method method : controllerClass.getDeclaredMethods()) {

      RequestMapping rm =
        method.getAnnotation(RequestMapping.class);
      if(rm == null) {
        continue;
      }
      else {

        String[] vals = rm.value();
        if (vals.length == 1) {
          this.mappingSet.add(vals[0]);
        }
        else {
          String msg =
            "this test assumes only one request mapping per method.  " +
            "check class: " + controllerClass + " and method: " + method;
          Assert.fail(msg);
        }
      }
    }
  }

Two notes:

  1. The reference "this.ctx" refers to a Spring ApplicationContext, in my case here an instance of the XmlWebApplicationContext class that loads my Spring configuration.
  2. The reference "this.mappingSet" is simply a class-local field (HashSet<String>) in which I simply store the RequestMapping values.
Finally, after this is complete I confirm that every menu item action URI is contained in the set of extracted RequestMapping values.

Friday, December 2, 2011

Five Weeks Post-Op

Today I'm five weeks out from knee surgery and it's doing awesome.  I started swimming again and after a hectic November travel schedule with a fifth anniversary vacation to Jamaica followed five days later by a trip to the in-laws for Thanksgiving I hope to establish more of a training routine because quite frankly I've lost my fitness and put on a little extra weight.  I'm not so much worried about the weight because it was gained from doing nothing for the first three weeks after the surgery and I gained nothing over Thanksgiving (a rare feat).  But I am disappointed about the loss of fitness because it's so damn hard to get back at first, i.e., the first week or two suck.

I remember when I took four months off after IM CDA in 2009 to let my foot fully heal that the first week or two I struggled to even run a mile.  Now that all the travelling is out of my schedule for the foreseeable future, I can start a training schedule again:  Master's swimming 2x a week and some trainer time.  I've been allowed to ride the trainer, but haven't gotten around to even setting it up yet.  This weekend for sure....along with all the other crap I have on my list.