90. @SessionAttribute와SessionStatus

1.     Com.springsource.javax.activation : Spring java-mail

2.     Com.springsource.javax.mail : Spring java-mail

3.     Com.springsource.javax.servlet.jsp.jstl : JstlView

4.     Com.springsource.org.aopalliance : Spring ProxyFactoryBean

5.     Com.springsource.org.aspectj.tools : AspectJExpressionPointcut 포인트컷 표현식 지원

6.     Com.springsource.org.cator.core : 자동으로 자바 오브젝트를 XML로 변환 지원.

7.     Com.springsource.org.cator.xml : 자동으로 자바 오브젝트를 XML로 변환 지원.

8.     Com.springsource.junit : junit

9.     Commons-logging : Spring-context가 사용

10.   Jackson-annotation : MappingJackson2JsonView

11.   Jackson-core : MappingJackson2JsonView

12.   Jackson-databind : MappingJackson2JsonView

13.   Mail : java-mail

14.   Mockito : 목 프레임워크 중 Mockito

15.   Mysql-connector : Mysql JDBC

16.   Org.springframework.context.support : Spring java-mail

17.   Org.springframework.oxm : Object-XML Mapping. 마샬러 빈을 지정해 모델에서 변환에 사용할 오브젝트를 지정해주면, OXM마샬러를 통해 모델 오브젝트를 XML로 변환해서 뷰의 결과로 사용할 수 있음.

18.   Spring-aop : 스프링 기능 자체의 aop, Spring ProxyFactoryBean

19.   Spring-bean : 스프링 코어와 함께 의존성 주입 제공 (Core Container)

20.   Spring-context : 스프링 코어, BeanFactory를 확장한 어플리케이션 컨텍스트 구현, 리소스 로드 및 국제화 지원(Core Container)

21.   Spring-core : 다른 스프링 모듈이 사용하는 유틸리티(Core Container)

22.   Spring-expression : EL 확장 Bean속성(배열, 컬렉션 포함).(Core Container)

23.   Spring-jdbc : 스프링이 지원하는 jdbc.

24.   Spring-test.jar

-       @RunWith : Junit 프레임워크의 테스트 실행방법을 확장시 사용.

-       SpringJUnit4ClassRunner : 어플리케이션컨텍스트를 만들고 관리하는 확장 클래스

-       @ContextConfiguration(경로) : 자동으로 만들어줄 어플리케이션 컨텍스트 설정파일

25.   Spring-tx : DuplicateKeyException.class 파일 존재 및 스프링 트랜잭션

26.   Spring-web : ContextLoaderListener 내장 루트 컨텍스트(서비스,DAO)

27.   Spring-webmvc : SpringMVC를 위한 리졸버, 모델앤뷰 등 지원

 

테스트 디스패처 서블릿을 위한 인터페이스

 

* 번거로운 XML 설정 대신 AbstractDispatcherServletTest를 사용

25. DispatcherServlet 초기화시 ServletConfig 오브젝트를 만들어 초기화해야함.

50. ContextRoot 값이 있을 때 추가해줌

54. setServletPath : 컨텍스트 root를 넣을 수 있도록 셋팅

58. request에 uri 정보와 get,post mothod 셋팅 및 리스판스 객체 생성

 

81. 테스트 DispatcherServlet Init

 

* 세션 도입의 필요성

> 사용자가 수정한 폼의 필드 값에 오류가 있는 경우에 에러 메시지와 함께 수정 화면을 다시 보여줘야 한다. 또, 상태를 유지하지 않고 폼 수정 기능을 만들려면 데이터 중심(SQL을 중심으로 한벌씩 만드는)의 방식이 되어 데이터 엑세스 계층과의 결합도가 높아진다.

* 도메인 중심의 프로그래밍 문제

> 사용자의 수정 폼에서 수정을 실행하면 ID값 등의 중요정보는 그대로고, 나머지 정보만 수정하는게 대부분이다. 이렇게 중요 정보를 제외한 나머지 정보가 업데이트 된다면 DAO 프로퍼티 값이 null이나 0이 되버리는 심각한 결과를 초래하게된다.

> 해결방안

1) hidden 필드에 값을 박으면 되지만 이는 브라우저의 HTML소스를 열어보면 필드 이름까지 쉽게 알아내 보안에 취약하다.

2) DB를 재조회하여 수정된 정보만 바꿔준다. DB의 부담이 증가

3) 계층 사이의 강한 결합 : 서비스는 도메인 중 name,password,email 3개의 필드만 수정한다는 것을 알고있어서 3개만 만든다던지, 3개의 필드만 수정하도록 SQL을 작성한다. 4개를 수정한다면 4개를 수정하는걸 다시 작성하여 계층마다 만들어야 한다. 이런 식으로 계층 간에 강한 의존성을 주고 결합도를 높이면 처음에는 만들기 쉽지만 애플리케이션이 복잡해지기 시작하면 단점이 드러난다. 코드의 중복이 늘어나 재사용하기 힘들고 중복되어 한쪽을 수정하면 연관된 코드도 다 함께 수정해야 한다.

* 위와 같은 문제로 인해 스프링의 접근 방법은 바로 세션을 이용하는 것이다.

 

* 노란줄 : @SessionAttribute 애노테이션을 클래스 레벨에 부여하고 폼의 정보를 담을 모델 이름을 넣어주는 것이 전부다.

32. @SessionAttribute

1) 메소드가 생성하는 모델정보 중에 @SessionAttribute에 지정한 이름과 동일한 것이 있다면 이를 세션에 저장해준다.

36. 35라인의 모델 오브젝트를 리턴하면, 모델에 추가할 오브젝트가 하나일 때 사용. user라는 이름으로 모델에 추가됨.

이런식으로 세션에 담고 뺄수가 있다.

2) @ModelAttribute가 지정된 파라미터가 있을 때 이 파라미터에 전달해줄 오브젝트를 세션에서 가져온다. 원래는 폼데이터를 가져오는 역할을하는 모델어트리뷰트지만 @세션어트리뷰트로 선언된 이름과 동일하다면, 그때는 먼저 세션에 같은 이름의 오브젝트가 존재하는지 확인하여 존재한다면 새로운 오브젝트를 만드는 대신 세션 오브젝트를 가져와 오브젝트로 사용하고, 폼데이터로 넘어온 데이터를 바인딩 해준다. 모델오브젝트의 이름이 충돌되지 않도록 주의.

40. setComplete() : @SessionAttribute 세션에 저장해뒀던 오브젝트를 제거한다.

* 등록폼에서도 필요하다.

> 복잡한 도메인의 경우 디폴트값을 보여주는 경우. 등록 폼의 입력 값에서도 잘못된 것이 있으면 다시 폼을 띄워야하는 경우.

> 스프링의 폼태그를 사용하기 위해

- 폼태그는 폼을 출력할 때 폼의 내용을 담은 모델 오브젝트를 필요로 한다. 폼의 초기에는 아무런 값을 안보여주는게 좋지만, 입력값 오류시 다시 처음부터 입력하는 폼을 보여주는 건 3류 웹사이트에서나 있을 법한 일이다.