8. Annotation 기반으로 JUnit4를 이용한 Spring TDD

@TransactionConfiguration(transactionManager = "transactionManager", defaultRollback=true)

@RunWith : 테스트를 실행할 org.junit.runner.Runner 구현 클래스를 지정할 수 있다.

스프링은 스프링 컨텍스트 설정 및 DI, 트랜잭션 처리 등을 지원해주는 Runner 구현 클래스를 제공하고 있다.

Junit 4 기반의 테스트에서 스프링 컨텍스트에 설정된 빈 객체를 사용하고 싶다면 SpringJunit4ClassRunner 클래스를 @RunWith 어노테이션 값으로 설정하면 된다.

@ContextConfiguration : 스프링 컨텍스트를 생성할 때 사용될 설정 파일의 경로

@Autowired, @Resource : 테스트 코드에서 필요로 하는 스프링 빈 객체 설정

• 트랜잭션 처리를 위한 설정

@TransactionConfiguration : 테스트 클래스에 적용되며, 트랜잭션 관리자와 기본 롤백 규칙을 설정한다.

@Rollback : 테스트 메소드에 적용되며, 메소드 단위로 롤백 규칙을 설정한다.

@NotTransactional : 트랜잭션을 적용하지 않을 메소드에 적용한다.

@Transactional : 테스트 클래스에 적용. 이 어노테이션을 적용함으로써 각 테스트 메소드는 트랜잭션 범위 내에서 실행된다.

만약 테스트 메소드에서 명시적으로 롤백 여부를 설정하고 싶다면 @Rollback 어노테이션을 사용하면 된다.

@Rollback(false)

테스트 메소드에 대한 트랜잭션이 시작되기 전에 어떤 초기화 작업을 해주어야 한다며, @BeforeTransaction 어노테이션이 적용된 메소드를 작성하면 된다.

반대로 트랜잭션이 종료된 이후에 정리 작업을 해주어야 할 경우에는 @AfterTransaction 어노테이션이 적용된 메소드를 작성하면 된다.

9. Reference

 

SQL Maps2.0 개발자가이드 ( 한글판 )
http://ibatis.apache.org/docs/java/pdf/iBATIS-SqlMaps-2_ko.pdf

SQL Maps2.0 tutorial( 한글판 )
http://ibatis.apache.org/docs/java/pdf/iBATIS-SqlMaps-2-Tutorial_ko.pdf

iBATIS 에서   생성되는  SQL 문을   보기   위한  log4j 셋팅
http://openframework.or.kr/JSPWiki/Wiki.jsp?page=IbatisLog4jSettingToShowSQL
 
Sql2ibatis
http://openframework.or.kr/JSPWiki/Wiki.jsp?page=Sql2ibatis

DDL2iBatis
http://openframework.or.kr/JSPWiki/attach/Hibernate/DDL2iBatis-exe.zip

Spring 2.5, Eclipse and JUnit 4.4
http://dertompson.com/index.php/2007/12/12/spring-25-eclipse-and-junit-44/

iBATIS 인 액션: 쉽고 강력한 SQL 매핑 프레임워크 아이바티스
- 클린턴 비긴.브랜든 구딘.래리 메도스 지음 | 이동국.손권남 번역,  위키북스

스프링 2.5 프로그래밍
- 최범균 , 가메출판사

 

7. iBATIS + Spring + transaction

<tx:advice> 태그 이용

 

 

@ Transactional 어노테이션을   이용

이 dW문서는 작년에 작성되었던데 얼마전 Spring과 관련하여 Acegi에 대해 살짝~
공부해 봐서 마침 dW에 글이 있나 찾아보니 역시나 있군요~

우리나라 말로하면 "아저씨"(지극히 저의 개인적인 생각)란 이름과 비슷한 아씨지(어떤분은 머 다른말로 표현하셨던데 어쩜 그게 더 비슷한거 같기도 하고) 

아무튼!

What is Acegi Security?

Acegi Security is a powerful, flexible security solution for enterprise software, with a particular emphasis on applications that use Spring. Using Acegi Security provides your applications with comprehensive authentication, authorization, instance-based access control, channel security and human user detection capabilities.

머~ 이런 일을 한다고 합니다~

로그인할때 해당 유저가 로그인할 권한이 있는지 Acegi  보안을 통해 접근할지 못하게 할지등등의 일을
처리할 수 있습니다.

Acegi로 자바 애플리케이션 보안화 하기, Part 1: 아키텍처 개요와 보안 필터 (한글)

이 문서에서의 내용은 Spring 프레임워크를 사용하여 IoC와 XML설정 파일을 이용해 보안처리를 하기위해 Acegi를 적용한 간단한 샘플 예제가 있습니다.

설정으로 보안과 관련해서 처리해야 할 일들을 줄일 수 있다면야~ 좋겠죠~?

스프링에서 벨로시티 뷰 템플릿 엔진을 사용하고 있는데 여기에 편리한 tools를 사용하기 위해서
필요한 설정을 기억하기 위해 기록합니다.

VelocityTools는 벨로시티 템플릿에서 숫자나 날짜, url등의 포맷팅을 지원하는 툴이고,
VelocityTools프로젝트에는 GenericTools, VelocityView, VelocityStruts 세개의 부분으로 나눠져 있습니다.

보통 GenericTools를 많이 쓸일이 많기 때문에~ 조금 정리해보면,

Generic Tools에는,

DateTool

A tool for manipulating and formatting dates.

MathTool

A tool for performing floating point math.

NumberTool

A tool for formatting numbers.

RenderTool

A tool to evaluate and render arbitrary strings of VTL (Velocity Template Language).

EscapeTool

A tool to help with common escaping needs in Velocity templates.

ResourceTool

A tool to simplify access to ResourceBundles for internationalization or other dynamic content needs.

Alternator and AlternatorTool

Utility class for easily alternating over values in a list and tool for easy creation of Alternators in templates.

ValueParser

A tool to retrieve and parse String values pulled from a map. This provides the basis for the ParameterParser in VelocityView.

ListTool

A tool to help when working with arrays or Lists. This tool transparently handles both the same way.

SortTool

A tool that allows a user to sort a collection (or array, iterator, etc) on any arbitary set of properties exposed by the objects contained within the collection.

IteratorTool

A convenience tool to use with #foreach loops. It wraps a list to let the designer specify a condition to terminate the loop, and reuse the same list in different loops.

EscapeTool
- It provides methods to escape outputs for Java, JavaScript, HTML, HTTP, XML and SQL. Also provides methods to render VTL characters that otherwise needs escaping.
을 이용하여 테스트 해보면...

toolbox.xml 파일을 하나 만들어서

genericTool의 EscapeTool을 사용하는데 velocity에서 esc라는 키워드를 이용해서 쓰겠다~


스프링에서 Properties파일을 따로 정의했다고 하면(따로 빼 놓았다면)


스프링의 설정파일에서



.vm라는 확장자의 velocity파일에서


결과는


참고 :

[Velocity] 스프링 프레임워크에서 사용하기

http://velocity.apache.org/tools/devel/javadoc/org/apache/velocity/tools/generic/EscapeTool.html
http://forum.springframework.org/archive/index.php/t-10926.html

빈의 후처리

스 프링은 빈의 생명주기에 끼어들어 빈의 설정을 재검토하거나 바꿀 수 있는 2개의 기회를 제공한다. 후처리는 어떤 이벤트가 발생한 후에 처리되는 것이라고 추측할 수 있다. 이벤트란 빈이 설정되거나 인스턴스화되는 것을 말한다. BeanPostProcessor 인터페이스는 빈이 생성되거나 묶인 후에 변경할 수 있는 두개의 기회를 제공

빈 팩토리의 후처리

BeanFactoryPostProcesor는 빈 팩토리가 빈의 정의를 로딩한 후와 빈이 인스턴스화되기 전에 빈 팩토리에 대해 후처리를 수행한다.

BeanFactoryPostProcessor의 유용한 구현 클래스 두 개

PropertyPlaceholderConfigurer

CustomEditorConfigurer

자동 묶기(Autowire)

자동 묶기의 네 종류

byName : 묶고자 하는 특성의 이름과 동일한 이름이나 ID를 가진 빈을 컨테이너에서 찾는다. 빈을 찾지 못하면 그 특성을 묶이지 않은 채로 남는다.

byType : 묶 고자 하는 특성의 타입과 동일한 타입을 가진 빈을 컨테이너에서 찾는다. 빈을 찾지 못하면 그 특성은 묶이지 않은 채로 남고, 하나 이상의 빈을 찾게 되면 org.springframework.beans.factory.UnsatisfiedDependencyException을 던진다.

Constructor : 묶고자 하는 빈의 생성자 중 하나의 파라미터와 맞는 하나 이상의 빈을 컨테이너에서 찾는다. 모호한 빈이나 생성자가 발견될 경우 org.springframework.beans.factory.UnsatisfiedDependencyException을 던진다.

Autodetect : constructor에 의한 자동 묶기를 먼저 시도한 다음, byType을 이용한다. 모호함이 발견될 경우 constructor와 byType 경우와 동일한 방법으로 처리한다.

자동 묶기의 모호성 다루기

byType 이나 constructor를 사용하여 자동 묶기를 하는 경우에는 컨테이너가 특성의 타입이나 생성자 인자의 타입에 부합하는 둘 이상의 빈을 찾는 것이 가능하다.

이렇듯 자동 묶기에 사용될 수 있는 모호한 빈들이 존재 할 경우 스프링은 모호성을 분별할 능력이 없으며, 묶고자 하는 빈을 추측하는 대신 예외를 던지는 방법을 선택한다.

자동 묶기를 할 때 그 같은 모호성을 만나게 된다면, 자동 묶기를 하지 않는 것이 가장 단순하면서도 좋은 해결책이다.

세터 주입(Setter Injection)의 대안 - 생성자 주입(Constructor Injection)

세터 주입은 빈 특성을 설정하고 묶을 수 있는 직관적인 방법이지만, 한 가지 단점은

변경될 수 있는 모든 특성이 세터 메소드를 통해서 사용할 수 있다고 가정하는 것에 있다. 하지만 빈이 이와 같은 방식으로 작동하기를 원하지 않을 때,

이런 유형의 빈이 인스턴스화될 때에는 어떤 특성도 설정될 수 없으며, 따라서 빈이 유효하지 않은 상태로 있을 가능성이 있다.

어떤 특성들은 빈이 생성될 때 한 번만 설정되고 그 이후에는 변경될 수 없도록 만들고 싶은 경우도 있다.

이는 세터를 통해 모든 특성을 공개하는 경우에는 곤란해진다.

대안은 일부 특성들은 생성자 를 통해 설정될 수 있도록 빈을 설계하는 것이다.

DAO의 DataSource와 같이 반드시 설정돼야 하고 변경되어서는 안 되는 특성이 있는 경우에 특히 유용

빈 묶기(Bean wiring)

XML로 묶기 : 다음을 이용해 스프링 컨테이너가 XML을 통한 빈 묶기를 지원한다.

XmlBeanFactory

ClassPathXmlApplicaionContext

FileSystemXmlApplicationContext

XmlWebApplicationContext

프로토타입과 싱글톤 비교

스프링의 모든 빈은 싱글톤. getBean()의 호출에 의해서든 묶기를 통해서든 간에, 컨테이너가 빈을 배포할 때에는 항상 그 빈의 완전히 동일한 인스턴스를 내줄 것이다.

scope="singleton"
scope="prototype"

프로토타입 빈을 정의하는 것이 유리할 때

프로토타입을 정의한다는 것은 실제 하나의 빈을 정의하는 것이 아닌, 청사진을 정의한다는 의미다. 그 다음엔 그 청사진을 바탕으로 빈들이 생성될 것이다.

프로토타입 빈은, 빈을 요청할 때마다 컨테이너가 빈의 유일한 인스턴스를 제공하기 원하면서도 그 빈의 하나 이상의 특성을 스프링을 통해 설정하고자 할 경우에 유용

프로토타입으로 정의

빈 의 이름을 사용해 getBean()을 호출할 때마다 프로토타입의 새로운 인스턴스가 생성된다. 이로 인해 데이터베이스나 네트워크 연결과 같은 제한된 자원을 사용하는 빈의 경우에는 적합하지 않다. 최소한 새로운 인스턴스가 생성될 때마다 약간의 성능 저하를 겪을 수 있기 때문에, 절대적으로 필요한 경우에만 프로토타입으로 빈을 정의하자.

Scope	Description
singleton	Scopes a single bean definition to a single object instance per Spring IoC container.
prototype	Scopes a single bean definition to any number of object instances.
request	Scopes a single bean definition to the lifecycle of a single HTTP request; that is each and every HTTP request will have its own instance of a bean created off the back of a single bean definition. Only valid in the context of a web-aware Spring ApplicationContext.
session	Scopes a single bean definition to the lifecycle of a HTTP Session. Only valid in the context of a web-aware Spring ApplicationContext.
global session	Scopes a single bean definition to the lifecycle of a global HTTP Session. Typically only valid when used in a portlet context. Only valid in the context of a web-aware Spring ApplicationContext.

출처 : spring 2.0 reference 중

 

초기화와 소멸

빈의 정이 내에 커스텀 init-method를 선언함으로써 빈이 인스턴스화되는 즉시 호출될 메소드를 지정할 수 있다.

커스텀 destroy -method는 빈이 컨테이너로부터 제거되기 직전에 호출될 메소드를 지정한다.

Example) 커넥션 풀링(connection pooling) 빈

public class MyConnectionPool{

public void initialize(){

//커넥션 풀 초기화

}

}

public void close(){

//연결 해제

}

}

빈의 정의는,

MyConnectionPool이 인스턴스화되자마자 initialize() 메소드가 호출,

빈이 컨테이너로부터 제거되기 직전에 close() 메소드를 호출

스프링은 또 다른 방법으로, InitializingBean과 DisposableBean이라는 동일한 역할을 하는 두개의 인터페이스를 제공한다.

이 방법은 인터페이스를 구현하는 빈을 스프링 컨테이너가 자동으로 탐지하며, 별다른 설정없이도 메소드를 호출해준다(XML 손대지 않고) 하지만, 인터페이스를 구현하게 되면, 빈은 스프링의 API에 묶이게 되어 버린다.

빈을 초기화하고 소멸시킬 때 가능하다면 init-method와 destroy-method 정의에 의존하는게 좋은 방법이다. 스프링의 인터페이스를 사용할만한 유일한 경우는 스프링 컨테이너 안에서 특별하게 사용될 프레임워크 빈을 개발할 때뿐이다.

스프링 컨테이너의 두 종류

컨테이너 안의 빈(Bean)

컨 테이너는 스프링 프레임워크의 핵심이다. 스프링 컨테이너는 제어 역행(IoC)을 사용해 애플리케이션을 구성하는 컴포넌트들을 관리한다. 여기에는 협력하는 컴포넌트간의 연관관계를 생성하는 것이 포함된다. 그렇게 함으로써 객체는 좀더 명확하게 이해할 수 있고, 재사용이 가능해지며, 단위테스트가 쉬워진다.

스프링 컨테이너의 두 종류

빈 팩토리(BeanFactory)

팩토리 디자인 패턴을 구현한 것. 빈 팩토리는 빈을 생성하고 분배하는 책임을 지는 클래스

커스텀 초기화 메소드(initialization method)와 소멸 메소드(destruction method)를 호출함으로써 빈의 생명주기에 개입할 수 있다.

org .springframework.beans.factory.xml.XmlBeanFactory 가 가장 유용한데, XML 파일에 기술돼있는 정의를 바탕으로 빈을 로딩한다.

빈 팩토리에게 XML 파일로부터 빈에 대한 정의를 읽어오라고 알려준다 . 빈 팩토리가 빈 을인스턴스화하는 것은 아니고 빈은 빈 팩토리에 “늦게 ”로딩되는데, 이 말은 빈 팩토리가 빈의 정의는 즉시 로딩하는 반면, 빈 자체가 필요하게 되기 전까지는 인스턴스화 하지 않는다.

getBean()이 호출되면, 팩토리는 의존성 주입을 이용해 빈을 인스턴스화하고 빈의 특성을 설정 시작. 여기서 빈의 일생이 시작된다.

애플리케이션 컨텍스트

BeanFactory와 유사한 기능을 제공하지만 좀 더 많은 기능을 제공하는 ApplicationCont ext

국제화(I18N) 지원을 포함해 텍스트 메시지를 해석하는 수단을 제공

이미지 등과 같은 자원을 로딩하는 범용적인 방법을 제공

리스너로 등록돼있는 빈에 이벤트를 발행할 수 있다.

구현 클래스 중 일반적으로 사용되는 세 개 의 클래스

ClassPathXmlApplicationContext : 클래스 경로에 있는 XML 파일로부터 컨텍스트 정의를 로딩하며, 컨텍스트 정의를 클래스 경로에 있는 자원으로 취급한다.

FileSystemXmlApplicationContext : 파일 시스템에 있는 XML 파일로부터 컨텍스트 정의를 로딩.

XmlWebApplicationContext : 웹 애플리케이션에 포함돼 있는 XML 파일로부터 컨텍스트 정의를 로 딩