스프링과 스프링부트 차이 (spring vs spring boot)

1. 설정 및 구성:

• 스프링: 스프링 프레임워크는 다양한 기능을 제공하지만, 이를 설정하는 데 많은 XML 구성 파일이나 Java 설정 클래스가 필요합니다. 개발자가 직접 빈(bean)을 정의하고 연결해야 하므로 초기 설정이 복잡할 수 있습니다.

• 스프링부트: 스프링부트는 자동 설정(autoconfiguration)을 통해 대부분의 설정 작업을 자동화합니다. 기본적인 프로젝트 설정과 함께 필요한 대부분의 의존성을 자동으로 구성해주기 때문에 설정 작업이 크게 줄어듭니다.

2. 프로젝트 구조 및 시작:

• 스프링: 스프링 프로젝트를 시작하려면 각종 라이브러리를 수동으로 추가하고 설정해야 합니다. 초기 세팅에 많은 시간이 걸릴 수 있습니다.

• 스프링부트: 스프링부트는 스타터 프로젝트(starter project) 개념을 도입하여 필요한 라이브러리를 쉽게 추가하고 설정할 수 있게 합니다. Spring Initializr와 같은 도구를 통해 몇 번의 클릭만으로 프로젝트를 생성할 수 있습니다.

3. 내장 서버:

• 스프링: 스프링에서는 애플리케이션을 실행하기 위해 별도의 서버(Tomcat, Jetty 등)를 설치하고 설정해야 합니다.

• 스프링부트: 스프링부트는 내장된 톰캣(Tomcat), 제티(Jetty), 언더토우(Undertow) 서버를 제공하여 별도의 서버 설치 없이 애플리케이션을 바로 실행할 수 있습니다.

4. 개발 생산성:

• 스프링: 강력하고 유연한 기능을 제공하지만, 설정과 구성이 복잡할 수 있어 초기 학습 곡선이 가파를 수 있습니다.

• 스프링부트: 설정의 단순화와 자동 구성을 통해 개발 생산성을 크게 향상시켜 줍니다. 코드 작성을 더 빠르고 간단하게 만들기 때문에 빠른 프로토타이핑과 개발이 가능합니다.

스프링 war 배포 vs 스프링부트 jar 배포

스프링(Spring) 애플리케이션을 사용할 때, 전통적으로 WAR 파일을 사용하여 배포하는 것이 일반적이었습니다. 이는 특히 스프링이 처음 등장했던 시절부터 많이 사용되었던 방식입니다. 하지만 최근 몇 년 동안 스프링부트(Spring Boot)의 등장으로 인해 JAR 파일로 배포하는 방식이 더 인기를 끌고 있습니다.

전통적인 스프링 애플리케이션과 WAR 파일

1. WAR 파일 사용 이유:

• 서버 배포: 전통적인 스프링 애플리케이션은 Tomcat, Jetty, JBoss 등과 같은 웹 애플리케이션 서버에 배포되었습니다. 이 서버들은 WAR 파일을 배포 유닛으로 사용합니다.

• 관리 및 스케일링: 여러 애플리케이션을 하나의 서버에서 관리하고 스케일링할 수 있는 장점이 있습니다.

2. WAR 파일 배포 과정:

• 애플리케이션 코드를 작성하고, 이를 WAR 파일로 패키징합니다.

• WAR 파일을 웹 애플리케이션 서버의 특정 디렉토리에 배포합니다.

• 서버가 WAR 파일을 인식하고 애플리케이션을 실행합니다.

스프링부트와 JAR 파일

스프링부트는 전통적인 스프링 애플리케이션의 복잡성을 줄이고, 보다 단순하게 애플리케이션을 개발하고 배포할 수 있게 도와줍니다. 이 과정에서 JAR 파일 배포가 주로 사용됩니다.

1. JAR 파일 사용 이유:

• 독립 실행형 애플리케이션: 스프링부트는 내장 톰캣(Tomcat) 등을 포함하여 JAR 파일 형태로 패키징되므로, 별도의 웹 애플리케이션 서버 없이 독립적으로 실행할 수 있습니다.

• 간편한 배포: JAR 파일 하나로 애플리케이션을 쉽게 배포하고 실행할 수 있어 배포 과정이 단순화됩니다.

2. JAR 파일 배포 과정:

• 애플리케이션 코드를 작성하고, 이를 JAR 파일로 패키징합니다.

• java -jar myapp.jar 명령어로 애플리케이션을 실행합니다.

결론

• 전통적인 스프링 애플리케이션: 주로 WAR 파일을 사용하여 웹 애플리케이션 서버에 배포.

• 스프링부트 애플리케이션: 주로 JAR 파일을 사용하여 독립 실행형 애플리케이션으로 배포.

스프링 프레임워크에서 객체 의존성을 관리하기 위해 주로 사용되는 세 가지 어노테이션인 @Autowired, @Resource, 그리고 @Inject에 대해 설명하고, 각각의 특징과 차이점을 비교해 드리겠습니다. 이 어노테이션들은 모두 의존성 주입(Dependency Injection, DI)을 수행하는 데 사용되며, 스프링 애플리케이션에서 중요한 역할을 합니다.

의존성 주입이란

의존성 주입(Dependency Injection, DI)은 소프트웨어 엔지니어링에서 사용되는 디자인 패턴 중 하나로, 객체가 자신의 의존성(즉, 다른 객체들)을 직접 생성하거나 검색하지 않고, 외부에서 받도록 하는 기술입니다. 이 패턴을 사용하면 컴포넌트 간의 결합도가 낮아지고, 유연성이 향상되며, 코드의 재사용성과 테스트 용이성이 증가합니다.

의존성 주입 어노테이션

1. @Autowired (Spring Framework)

• 라이브러리: Spring Framework

• 기능: 타입에 기반하여 자동으로 의존성을 주입합니다. 만약 타입이 일치하는 빈이 여러 개 있는 경우, 필드 이름이나 파라미터 이름으로 빈을 구별하여 주입합니다.

• 주입 방법: 필드, 세터, 생성자 주입이 가능하며, 생성자 주입이 권장됩니다.

• 특징: @Autowired는 스프링의 기본 설정에서 자동으로 사용될 수 있으며, required 속성을 통해 의존성이 필수적인지 선택적인지 지정할 수 있습니다.

2. @Resource (Java Standard)

• 라이브러리: JSR-250, Java Standard

• 기능: 주로 이름에 기반하여 의존성을 주입합니다. 이름을 명시하지 않으면 필드의 이름 또는 세터 메서드의 이름을 사용합니다. 이름으로 적합한 빈을 찾지 못하면 타입에 의해 주입을 시도합니다.

• 주입 방법: 필드 및 세터 메서드에 사용될 수 있습니다.

• 특징: @Resource는 Java EE에서 제공되며, 스프링과 같은 DI 컨테이너에서도 사용할 수 있습니다. 스프링에서는 @Autowired보다는 약간 더 명시적인 의존성 주입 방식을 제공합니다.

3. @Inject (Java Dependency Injection)

• 라이브러리: JSR-330, Java Dependency Injection standard

• 기능: 타입에 기반하여 의존성을 주입합니다. @Autowired와 유사하게 작동하지만, required 속성이 없습니다.

• 주입 방법: 필드, 세터, 생성자 주입이 가능하며, 역시 생성자 주입이 권장됩니다.

• 특징: @Inject는 Java의 표준 의존성 주입 규약을 따르며, 스프링 뿐만 아니라 다른 DI 프레임워크에서도 사용될 수 있습니다. 스프링에서는 @Autowired와 거의 동일하게 작동하지만, 스프링 특유의 기능인 required 속성을 지원하지 않습니다.

비교

• 유연성 및 호환성: @Inject와 @Resource는 Java 표준을 따르므로, 다른 Java 기반 프레임워크로의 이동성이 더 높습니다. 반면, @Autowired는 스프링에 종속적입니다.

• 기능성: @Autowired는 required 속성을 통해 의존성이 필수인지 여부를 설정할 수 있어 더 많은 유연성을 제공합니다. @Inject는 이러한 속성이 없습니다.

• 사용의 용이성: @Autowired는 스프링 프레임워크에서 가장 일반적으로 사용되며, 스프링 특화 기능

위의 키워드 로 의존성 주입을 구현하는 방법

의존성 주입의 구현 방법

1. 생성자 주입: 객체를 생성할 때 생성자를 통해 의존성을 전달합니다. 이 방법이 가장 권장되는 방식으로, 객체의 불변성을 보장할 수 있습니다.

2. 세터 주입: 객체 생성 후 세터 메서드를 통해 의존성을 주입합니다. 생성자 주입에 비해 유연성은 높지만, 객체의 완전성을 보장받기 어려울 수 있습니다.

3. 필드 주입: 리플렉션을 사용하여 직접 필드에 의존성을 주입합니다. 코드는 간결해지지만, 다른 주입 방식에 비해 많은 단점을 가지고 있으며 권장되지 않습니다.

1. 생성자 주입(Constructor Injection)

생성자 주입은 가장 권장되는 방식입니다. 객체가 생성될 때 모든 의존성이 완전히 주입되기 때문에, 객체가 일관된 상태를 유지할 수 있습니다.

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class UserService {
    private final UserRepository userRepository;

    @Autowired
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    // UserService의 메서드
}

2. 세터 주입(Setter Injection)

세터 주입은 선택적 의존성이 필요할 때 유용할 수 있습니다. 이 방법을 사용하면 객체 생성 후 필요에 따라 의존성을 설정할 수 있습니다.

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class UserService {
    private UserRepository userRepository;

    @Autowired
    public void setUserRepository(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    // UserService의 메서드
}

3. 필드 주입(Field Injection)

필드 주입은 코드는 간결하지만, 많은 단점을 가지고 있습니다. 특히, 테스트가 어렵고 순환 참조 문제가 발생할 수 있습니다. 따라서 권장되지 않는 방법입니다.

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;

    // UserService의 메서드
}

생성자 주입을 간단하게 해주는 어노테이션

@RequiredArgsConstructor는 Lombok 라이브러리의 주요 어노테이션 중 하나입니다. 이 어노테이션은 자바 클래스에 대해 필요한 생성자를 자동으로 생성해 주는 기능을 제공합니다. 사용하게 되면, 명시적으로 생성자를 작성하지 않아도 되므로 코드의 간결성을 유지할 수 있습니다.

@RequiredArgsConstructor의 작동 방식

@RequiredArgsConstructor 어노테이션이 적용된 클래스는 모든 final 필드와 @NonNull 어노테이션이 붙은 필드에 대한 생성자를 자동으로 생성합니다. 이 생성자는 해당 필드들을 초기화하는 역할을 하므로, 객체가 올바르게 구성되도록 보장합니다.

주요 특징

• 자동 생성자 생성: 클래스의 final 필드 또는 @NonNull이 붙은 필드에 대한 생성자를 자동으로 생성합니다.

• 코드의 간결성 증가: 생성자를 직접 작성하지 않아도 되므로, 코드를 더 간결하게 유지할 수 있습니다.

• 객체 불변성 지원: final 필드에 대한 생성자를 자동으로 생성하기 때문에 불변 객체를 만드는 데 유용합니다.

• Null 안정성 강화: @NonNull 어노테이션이 붙은 필드는 생성자에서 null 검사 로직을 자동으로 추가하여, 객체 생성 시 null이 되지 않도록 강제합니다.

import lombok.NonNull;
import lombok.RequiredArgsConstructor;

@RequiredArgsConstructor
public class User {
    private final String name;
    private final int age;
    @NonNull
    private String email;

    // Lombok이 자동으로 다음 생성자를 생성해줍니다.
    // public User(String name, int age, String email) {
    //     this.name = name;
    //     this.age = age;
    //     this.email = Objects.requireNonNull(email, "email is required");
    // }
}

스프링 EL(Expression Language) 란 객체 그래프를 조회하고 조작하는 기능을 제공하는 언어를 말한다.

spEL은 모든 스프링 프로젝트에서 사용하는 expression language로 만들었다.

문법이나 규칙은 배우기가 쉽다.

• #{"표현식"}

• ${"프로퍼티"}

• 이런식으로 특정 객체를 가져와서 문자열처럼 사용할 수 있고, 계산도 할 수 있다. 표현식은 프로퍼티를 포함할 수 있지만, 반대로는 불가능하다.

사용처

• @Value 애노테이션 안에 spEL을 쓰면, 아래 필드값에 결과가 주입된다.
• 스프링 시큐리티의 경우 메소드 시큐리티, @PreAuthorize, @PostAuthorize, @PreFilter, @PostFilter, XML 인터셉터 URL 설정 등에 사용된다.
• 스프렝 데이터에서 @Query 에 사용된다.
• 화면을 만드는 템플릿엔진인 타임리프(thymeleaf) 등에서도 사용된다.

예시

@Value("#{1 + 1}")
int value;
 
@Value("#{'안녕 ' + 'red'}")
String greeting;

@Value("#{1 eq 1}")
boolean yn;

@Value("red")
String red;

// application.properties (프로퍼티) 에서 blue.value 변수를 가져온다.
@Value("${blue.value}")
int blueValue;

// Sample 객체의 data 필드 값을 가져온다.
@Value("#{sample.data}")
int sampleData;

사용 종류

Default Value

@Value("${car.type:Sedan}")
private String type; // yml 에 값이 없으면 Sedan 로 default value 설정

System Variables

@Value("${user.name}")
// Or
@Value("${username}")
private String userName;

@Value("${number.of.processors}")
// Or
@Value("${number_of_processors}")
private int numberOfProcessors;

@Value("${java.home}")
private String java;

Parameter Method Value

@Value("${car.brand}")
public CarData setCarData(@Value("${car.color}") String color, String brand) {
    carData.setCarColor(color);
    carData.setCarBrand(brand);
}

systemProperties

@Value("#{systemProperties['user.name']}")
private String userName;

@Value("#{systemProperties}")
private Map<String, String> properties;

public Driver(@Value("#{systemProperties['user.name']}") String name, String location) {
    this.name = name;
    this.location = location;
}

Injecting into Maps

student.hobbies={indoor: 'reading, drawing', outdoor: 'fishing, hiking, bushcraft'}

@Value("#{${student.hobbies}}")
private Map<String, List<String>> hobbies;

spring kill 시키기

SIGTERM 과 SIGKILL

주의해야할 것은 "정상(?) 종료" 되었을 때에 호출된다는 것이다.
무슨 말이냐면 애플리케이션이 종료될 때 일반적인 인터럽트는 SIGTERM 이라는 인터럽트다.
이 인터럽트(SIGTERM)가 발생하면 이벤트로 감지하고 수행하는 작업이라는 것이다.
SIGTERM을 정상적인 종료라고 봤을 때, 비정상 종료는 SIGKILL 이다.
리눅스에서 kill -9 옵션과 같이 강제적으로 꺼버리는 것과 윈도우에서 작업관리자가 작업을 끝내버리는 등의 인터럽트가 SIGKILL이다.
위의 예제를 따라했는데 종료 이벤트에 대한 메서드가 호출되지 않았다면 SIGKILL을 이용해서 종료했을 가능성이 높다.
혹시나하고 윈도우 환경에서 커맨드창에 ctrl + c 로 종료해보았는데 이 단축키는 SIGTERM을 발생하는 이벤트라서 온전히 종료되는 것을 아래 그림에서 볼 수 있다.

kill 시킬시

kill -9 는 급 종료
kill -15 는 현재 프로세스 다 실행시키고 종료 

권장 종료 방법

$kill -term 프로세스ID

kill -term 이 -15 와 동일하다

$ kill -l

1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR

참고문헌

https://jeong-pro.tistory.com/179 [SIGTERM 과 SIGKILL 및 스프링종료시 생명주기]
https://heowc.dev/2018/12/27/spring-boot-graceful-shutdown/ [스프링boot 안전하게 종료하기]
https://www.baeldung.com/spring-boot-shutdown [스프링 boot 종료 공식 문서]
www.lesstif.com/system-admin/unix-linux-kill-12943674.html [kill 종료 명령어 코드 및 방법]

mockMvc 사용준비

@Autowired
SampleController sampleController;

private MockMvc mockMvc;

@Before
public void 기본() throws Exception{
	mockMvc = MockMvcBuilders.standaloneSetup(sampleController).build();

}

기본 get 방식 test

@Test
public void get_sample() throws Exception{
    RequestBuilder reqBuilder = MockMvcRequestBuilders.get("/test" + 1)
    .param("param1", param1)
    .param("param2", param2)
    .param("param3", param3);
    this.mockMvc.perform(reqBuilder).andExpect(status().isOk()).andDo(print());
}

post @requestBody 요청

public static final MediaType APPLICATION_JSON_UTF8 = new MediaType(MediaType.APPLICATION_JSON.getType(), MediaType.APPLICATION_JSON.getSubtype(), Charset.forName("utf8"));

@Test
public void 제이슨_바디리퀘스트() throws Exception{
   RequestBuilder reqBuilder = MockMvcRequestBuilders.post("/test/" + 1)
                 .header("header1", header1)
                 .header("header2" , header2)
                 .contentType(APPLICATION_JSON_UTF8)
                 .content(requestJson);

   this.mockMvc.perform(reqBuilder).andExpect(status().isOk()).andDo(print());
}

메소드 사용법

andDO

요청에 대한 처리를 합니다. print() 메소드가 일반적입니다.

.andDo(print())

andExpert

예상값을 검증합니다. assert* 메소드들과 유사합니다.

// status 값이 정상인 경우를 기대하고 만든 체이닝 메소드 중 일부입니다.
.andExpect(status().isOk())
// contentType을 검증합니다.
.andExpect(content().contentType("application/json;charset=utf-8"))

andReturn

테스트 클래스에서 작성은 안했지만 테스트한 결과 객체를 받을 때 사용합니다.

MvcResult result = this.mockMvc.perform(get("/"))
.andDo(print())
.andExpect(status().isOk())
.andExpect(model().attributeExists("serverTime"))
.andReturn();

Transactions

마이바티스 스프링 연동모듈을 사용하는 중요한 이유중 하나는 마이바티스가 스프링 트랜잭션에 자연스럽게 연동될수 있다는 것이다.
마이바티스에 종속되는 새로운 트랜잭션 관리를 만드는 것보다는 마이바티스 스프링 연동모듈이 스프링의 DataSourceTransactionManager과 융합되는 것이 좋다.

설정을 하면 스프링에서 트랜잭션 가능

@Transactional 애노테이션과 AOP스타일의 설정 모두 지원한다. 하나의 SqlSession객체가 생성되고 트랜잭션이 동작하는 동안 지속적으로 사용될것이다. 세션은 트랜잭션이 완료되면 적절히 커밋이 되거나 롤백될것이다.

<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
  <property name="dataSource" ref="dataSource" />
</bean>

트랜잭션 관리자에 명시된 DataSource가 SqlSessionFactoryBean을 생성할때 사용된 것과 반드시 동일한 것이어야 하는 것만 꼭 기억하자. 그렇지 않으면 트랜잭션 관리가 제대로 되지 않을것이다.

Transactions 주의사항

@Transactional 어노테이션은 Proxy기반이므로 내부 메소드 호출인 경우 트랜잭션이 적용되지 않는다. 즉 현재 클래스의 메소드가 아닌 다른 클래스의 메소드에 트랜잭션을 걸어야 한다.
서비스 메소드에만 가능!!. private 메소드에는 안됨!

문서

http://www.mybatis.org/spring/ko/transactions.html

참고문헌

http://ojc.asia/bbs/board.php?bo_table=LecSpring&wr_id=500

mapper 등록하기

xml 설정

매퍼는 다음처럼 XML설정파일에 MapperFactoryBean을 두는 것으로 스프링에 등록된다.

<bean id="userMapper" class="org.mybatis.spring.mapper.MapperFactoryBean">
  <property name="mapperInterface" value="org.mybatis.spring.sample.mapper.UserMapper" />
  <property name="sqlSessionFactory" ref="sqlSessionFactory" />
</bean>

MapperFactoryBean은 SqlSessionFactory 나 SqlSessionTemplate가 필요하다. sqlSessionFactory 와 sqlSessionTemplate 프로퍼티를 셋팅하면 된다. 둘다 셋팅하면 SqlSessionFactory가 무시된다. 세션 팩토리 셋은 SqlSessionTemplate이 필요하고 MapperFactoryBean는 팩토리를 사용할것이다.

자바 설정

@Bean
public SqlSessionFactory sqlSessionFactory() throws Exception {
  SqlSessionFactoryBean sqlSessionFactory = new SqlSessionFactoryBean();
  sqlSessionFactory.setDataSource(dataSource());
  return (SqlSessionFactory) sqlSessionFactory.getObject();
}

@Bean
public UserMapper userMapper() throws Exception {
  SqlSessionTemplate sessionTemplate = new SqlSessionTemplate(sqlSessionFactory());
  return sessionTemplate.getMapper(UserMapper.class);
}

마이바티스의 디폴트 SqlSession에서 매퍼를 리턴받을수 없다. 디폴트 SqlSession은 쓰레드에 안전하지 않고 생성된 SqlSession이 닫힐때까지만 살아있기 때문이다. 대신 샘플코드에서 보여주는 것처럼 SqlSessionTemplate 를 사용해야만 한다

mapper 스캐닝

위는 매퍼를 수동으로 등록하는 방법이고, 정상적이라면 mapper 를 스캔해서 등록해야 한다.
스캔방법에는 3가지가 있다.

• 1. mybatis:scan/ 엘리먼트 사용
• 2. @MapperScan 애노테이션 사용
• 3. 스프링 XML파일을 사용해서 MapperScannerConfigurer를 등록

1. mybatis:scan/ 엘리먼트 사용

'mybatis:scan/' XML엘리먼트는 스프링에서 제공하는 'context:component-scan/' 엘리먼트와 매우 유사한 방법으로 매퍼를 검색할 것이다.

<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:mybatis="http://mybatis.org/schema/mybatis-spring"
  xsi:schemaLocation="
  http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
  http://mybatis.org/schema/mybatis-spring http://mybatis.org/schema/mybatis-spring.xsd">
  <mybatis:scan base-package="org.mybatis.spring.sample.mapper" />
</beans>

2. @MapperScan 애노테이션 사용

@Configuration 을 사용해서 사용해야 한다.

@Configuration
@MapperScan("org.mybatis.spring.sample.mapper")
public class AppConfig {

  @Bean
  public DataSource dataSource() {
    return new EmbeddedDatabaseBuilder().addScript("schema.sql").build()
  }
  @Bean
  public SqlSessionFactory sqlSessionFactory() throws Exception {
    SqlSessionFactoryBean sessionFactory = new SqlSessionFactoryBean();
    sessionFactory.setDataSource(dataSource());
    return sessionFactory.getObject();
  }
}

3. 스프링 XML파일을 사용해서 MapperScannerConfigurer를 등록

MapperScannerConfigurer

<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
  <property name="basePackage" value="org.mybatis.spring.sample.mapper" />
</bean>

참고문헌

http://www.mybatis.org/spring/ko/mappers.html

SqlSessionFactory

SqlSessionFactory는 데이터베이스와의 연결과 SQL의 실행에 대한 모든 것을 가진 가장 중요한 객체다.
이 객체가 DataSource를 참조하여 MyBatis와 Mysql 서버를 연동시켜준다.

SqlSessionFactory를 생성해주는 SqlSessionFactoryBean 객체를 먼저 설정하여야 한다.
root-context.xml

<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
    <property name="dataSource" ref="dataSource"></property>
</bean>

cofing

MyBatis는 SQL Mapping 프레임워크로 별도의 설정 파일을 가질 수 있다.
src/main/resources에 mybatis-config.xml 파일을 추가

<!-- mybatis-config.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE configuration
    PUBLIC "-//mybatis.org//DTD Config 3.0//EN"
    "http://mybatis.org/dtd/mybatis-3-config.dtd">
<configuration>

</configuration>

Mybatis에 별도의 설정을 주고 싶으면 위의 파일을 이용
root-context.xml의 sqlSessionFactory에 다음과 같이 configLocation 속성을 추가

<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
    <property name="dataSource" ref="dataSource"></property>
    <property name="configLocation" value="classpath:/mybatis-config.xml"></property>
</bean>

설정파일이 필요한 다른 이유는 마이바티스 XML파일이 매퍼 클래스와 동일한 클래스패스에 있지 않은 경우이다. 이 설정을 사용하면 두가지 옵션이 있다.
첫번째는 마이바티스 설정파일에 섹션을 사용해서 XML파일의 클래스패스를 지정하는 것이다.
두번째는 팩토리 빈의 mapperLocations 프로퍼티를 사용하는 것이다.

<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
  <property name="dataSource" ref="dataSource" />
  <property name="mapperLocations" value="classpath*:sample/config/mappers/**/*.xml" />
</bean>

Test

SqlSessionFactory를 이용해 MyBatis와 Mysql 서버가 제대로 연결되는지 테스트
rc/test/java 폴더에 MyBatisTest라는 파일 생성

public class MyBatisTest {
    //SqlSessionFactory 객체를 자동으로 생성
    @Inject
    private SqlSessionFactory sqlFactory;
    //SqlSessionFactory 객체가 제대로 만들어졌는지 Test
    @Test
    public void testFactory() {
        System.out.println(sqlFactory);
    }
    //MyBatis와 Mysql 서버가 제대로 연결되었는지 Test
    @Test
    public void testSession() throws Exception{
        try(SqlSession session = sqlFactory.openSession()){
            System.out.println(session);
        }catch(Exception e) {
            e.printStackTrace();
        }
    }
}

API 문서

https://mybatis.org/mybatis-3/apidocs/org/apache/ibatis/session/SqlSessionFactory.html

참고문헌

http://www.mybatis.org/spring/ko/factorybean.html