Ace-T's Blog 내 검색 [네이버 커넥트 이웃 합니다~^-^/ 요청 大 환영~~]

Spring WebFlux

OpenSource/Spring 2017.04.26 17:40
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T

toby님이 회사에 오셨다.
스프링캠프 2017을 등록 못해서 못갔는데 다행히 좋은 강의를 들을수 있어서 좋았다.

강의자료 : 

Spring WebFlux
 람다식 
 추가 : 구 Spring web reactive 
  •  용도
    • 서비스간 호출이 많은 마이크로서비스 아키텍처에 적합.
    • 비동기 - 논블럭킹 개발방식.
    • 성능을 뛰어나게 만들겠다.
  • 기존 @MVC 방식, 새로운 방식
  • 서블릿 스택과 api에서 탈피
  • 블록킹, 논블록킹
    • 동기, 비동기와는 관점이 다름.
    • 내가 직접 제어할 수 없는 대상을 상대하는 방법
    • 대상이 제한적임
      • IO
      • 멀티 쓰레드 동기화 
  • 함수형 스타일의 콜백 방식

스프링 웹
1. 요청 매핑
2. 요청 바인딩
3. 핸들러 실행
4. 핸들러 결과 처리(응답 생성)

WebFlux
  • Router Function - 1. 요청매핑 (.route())
    • 함수형 스타일 (람다식..)
  • Handler Function - 2,3,4

RouterFunction의 등록 -> @Bean으로 만든다.
and(), andRoute(), nest() 등의 유용 메소드들.
flatMap

장점
  • 모든 웹 요청 처리 작업을 명시적인 코드로 작성.
  • 어노테이션에 의존하는 @MVC 스타일보다 명확
  • 정확한 타입 체크 가능.
  • 함수 조합을 통한 편리한 구성, 추상화에 유리
  • 테스트 작성의 편리함.

단점
  • 함수형 스타일의 코드가 익숙치 않음.
  • 기존 방식 가능

섞어서 사용 가능.
@MVC 요청 바인딩 + return Mono/Flux 사용.

WebFlux와 리액티브 기술
블로킹 IO 사용 X

JPA - JDBC 기반 RDB 연결
현재는 노답. - 블로킹 메소드로 점철된 jdbc api
JDK 10에서 Async JDBC가 등장할 수도(빠른 시간내에 적용)
@Async (적절한 쓰레드풀을 사용)
단, MongoDB, Redis, CouchDB등 Async 가능.

Spring5 함수형 스타일..

ReactiveStreams
RxJava를 비롯한 다양한 리액티브 기수에 적용된 표준 인터페이스
자바9에 Flow api로 포함.

뭘 공부해야하나?
java8 + 함수형 프로그래밍에 익숙해질 것.
Completablefuture와 같은 비동기 작업의 조합, 결합에 뛰어난 툴에 사용법을 익힐 것.

ReactorCore 학습 

열심히 공부하자+ㅁ+ㅋㅋ


저작자 표시 비영리 변경 금지
신고

'OpenSource > Spring' 카테고리의 다른 글

Spring WebFlux  (0) 2017.04.26
ChainedTransactionManager를 이용한 글로벌트랜잭션  (0) 2013.08.22
Bug  (0) 2013.06.21
@Vaild 처리 시 주의 할 사항!!  (0) 2013.06.21
Spring jmsTemplate 사용하기  (0) 2013.03.26
HornetQ, JMS Client using Springframework and Maven  (0) 2013.03.22

acet 박태하가 추천하는 readtrend 추천글!

설정

트랙백

댓글

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

ace-t의 Spring Boot 따라잡기(기본 - SourceTree에 연결 및 Repository에 올리기)

OpenSource/Spring Boot 2016.03.23 11:49
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T

1. 로컬에 있는 소스를 소스트리에 연동 시킵니다.




2. 아래와 같이 gitignore.io에 접속하여 커밋하면 안되거나 불필요한 액션을 줄이기 위해 ignore할 파일들에 대해서 Generate 해줍니다.

 https://www.gitignore.io/




/.git/info의  exclude에 위에서 생성되어진 내용을 붙여넣기를 해준다.

붙여넣을 내용.

더보기


그러한 뒤에 github에 push를 해주면 된다.



  - 끝 -


저작자 표시 비영리 변경 금지
신고

acet 박태하가 추천하는 readtrend 추천글!

설정

트랙백

댓글

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

[Ace-T의 Spring강좌] Step 06. Spring @MVC 분석-03

OpenSource/Spring 강좌 2014.05.23 11:32
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T

[Ace-T의 Spring강좌] Step 06. Spring @MVC 분석-03


저번 시간에는 spring context 구조 잡기, bootstrap 연동해보기 등등을 해보았네요!

이번 시간에는~! mvc구조를 한번 들어가보려고 합니다! ㅎㅎ두둥~

출처 : 토비의 스프링 3.2 / 토비형님 항상 감사합니다! 스프링책은 토비님 책이 짱짱맨!


아래의 소스링크가 안된다는 제보를 주셔서 소스는 아래의 github를 사용해주시면 감사하겠습니다.

제보주신 장땡땡님! 감사합니다^^

https://github.com/ace-t/rndStart/


우선 아래의 그림을 보시죵!~

차근차근 하나씩 MVC의 각 요소와 프론트 컨트롤러(DispatcherServlet)가 어떻게 협력해서 일하는지를 알아봅시다!

(1) DispatcherServlet의 HTTP 요청 접수

     Client에서 HTTP요청이 들어오면 web.xml의 url-pattern에 따라 DispatcherServlet에 할당된 것이라면

     HTTP 요청정보를 DispatcherServlet에 전달 해준다.


 URL이 / 로 시작하는 모든 요청을 DispatcherServlet에 할당해주는 것이다.^-^Good~

  위의 내용처럼 특정 폴더 아래의 내용을 매핑하는 방법도 가능하고, *.do와 같이 특정 확장자만을 매핑해주는 방법도 쓸 수 있다.


(2) DispatcherServlet에서 컨트롤러로 HTTP 요청 위임

     Controller를 선정하는 것은 DispatcherServlet의 핸들러 매핑 전략을 이용한다.

     핸들러 매핑 전략?? 이게 무슨말이냐하면..

     사용자(Client) 요청을 기준으로 어떤 컨트롤러/핸들러에게 작업을 위임할지를 결정 해준다는 것이다.

     그 다음으로는 해당 컨트롤러 오브젝트의 메소드를 호출해서 실제로 웹 요청을 처리하는 작업을 위임한다.

     또한 DispatcherServlet은 어떤 Controller라도 사용이 가능하다. 확장성이 좋다는 말이다.

     그렇다면 자바의 오브젝트 사이에 무엇인가 요청이 전달되려면 메소드를 호출할 수 있는 방법이 있어야 하지 않는가?

     어떻게 제각각 다른 메소드와 포맷을 가진 오브젝트를 Controller로 만들어놓고 DispatcherServlet이 이를 알아서

     호출하게 만들수 있을까? 

 

     바로! 전형적인 "어댑터 패턴"을 사용해서, 특정 Controller를 호출해야 할 때는 해당 Controller 타입을 지원하는 어댑터를

     중간에 껴서 호출하는 것이다. 그러면 DispatcherServlet은 항상 일정한 방식으로 Controller를 호출하고 결과를 

     받을수있다.

     

 아래의 그림처럼 DispatcherServlet은 Controller가 어떤 메소드를 가졌고 어떤 인터페이스를 구현했는지 전혀 알지 못한다.

 대신에 Controller종류에 따라 적절한 어댑터를 사용한다.

각 어댑터는 자신이 담당하는 Controller에 맞는 호출 방법을 이용해서 Controller에 작업을 요청하고 결과를 리턴받아서

 DispatcherServlet에게 다시 돌려주는 기능을 가지고 있다. WoW!


(Tip) DispatcherServlet이 핸들러 어댑터에 웹 요청을 전달할 때는 모든 웹 요청 정보가 담긴 HttpServletRequest 타입의 오브젝트를 전달해준다. 이를 어댑터가 적절히 변환해서 Controller의 메소드가 받을수 있는 파라미터로 변환해서 전달 해준다.

  

(3) Controller의 모델 생성과 정보 등록

     Controller가 하는 일은??

      1) 먼저 사용자 요청을 해석하는 것

      2) 그에 따라 실제 비즈니스 로직을 수행하도록 서비스 계층 오브젝트에게 작업을 위임하는 것

      3) 결과를 받아서 모델을 생성하는 것

      4) 어떤 뷰를 사용할지 결정하는 것


     특히 모델을 생성하고 모델에 정보를 넣어주는 작업은 매우 중요하다! Controller가 어떤식으로든 

     다시 DispatcherServlet에게 리턴해야 할 2가지 정보가 있는데, 그중 하나가 모델이고 다른 하나가 뷰이다.

     (Tip) 모델은 이름과 오브젝트 값의 쌍으로 만들어진다.(보통 맵에 담긴 정보라고 생각하면 된다.)


(4) Controller의 결과 리턴 : 모델과 뷰

     모델이 생성이 되었다면, 다음은 뷰를 결정할 차례이다.

     Controller가 뷰 오브젝트를 직접 리턴할 수도있지만, 보통은 뷰의 논리적인 이름을 리턴해주면 DispatcherServlet의

     전략인 뷰 리졸버가 이를 이용해 뷰 오브젝트를 생성해준다.(뷰를 사용하는 전략과 방법은 매우 다양하다!)

     결국 Controller가 리턴하는 것은 모델과 뷰 두가지이다.

     Spring에는 ModelAndView라는 이름의 오브젝트가 있는데, 이 ModelAndView가 DispatcherServlet에 

     어댑터를 통해 Controller로부터 돌려받는 오브젝트이다. 이름 그대로 모델과 뷰, 두가지 정보를 담고 있다.

     모델과 뷰를 넘기는 것으로 Controller의 책임은 끝이다. 다시 작업은 DispatcherServlet으로 넘어간다.


(5) DispatcherServlet의 뷰 호출과 (6) 모델 참조

     DispatcherServlet이 Controller로부터 모델과 뷰를 받은 뒤에 진행하는 작업은, 뷰 오브젝트에게 모델을 전달해주고 

     클라이언트에게 돌려줄 최종 결과물을 생성해달라고 요청하는 것이다.

     모델의 참조는 뷰에다가 데이터를 전달하는 것으로 보면 된다. 

     그리고 보통 브라우저를 통해 사용자가 결과를 본다고 하면 브라우저에 나타날 HTML을 생성하는 일이 가장 흔한 뷰의 작업이다.

     (Tip) 뷰 작업을 통한 최종 결과물은 HttpServletResponse Oject안에 담긴다. 


(7) HTTP 응답 돌려주기

     뷰 생성까지 모든 작업을 마쳤으면 DispatcherServlet은 등록된 후처리기가 있는지 확인하고, 있다면 후처리기에서 

     후속 작업을 진행한 뒤에 뷰가 만들어준 HttpServletResponse에 담긴 최종 결과를 서블릿 컨테이너에게 돌려준다.

     서블릿 컨테이너는 HttpServletResponse에 담긴 정보를 HTTP 응답으로 만들어 사용자의 브라우저나 클라이언트에게 

     전송하고 작업을 종료한다.






참고만 하세요! - 더 Detail하게는 좀 더 뒤에! ㅎㅎ

DispatcherServlet의 DI 가능한 전략

  "(2) DispatcherServlet에서 컨트롤러로 HTTP 요청 위임"에서의 전략에 대해서 알아보도록 하겠습니다~

  전략으로는 아래와 같이 Mapping과 Adapter가 있겠습니다~

  ㅇ HandlerMapping

      핸들러 매핑은 URL과 요청 정보를 기준으로 어떤 핸들러 오브젝트, 즉 Controller를 사용할 것인지를 결정하는 로직을 담당!

      default로 BeanNameUrlHandlerMapping과 DefaultAnnotaionHandlerMapping 두가지가 설정 되어있다.

      default 핸들러 매핑으로 충분하다면 추가로 핸들러 매핑을 등록하지 않아도 된다.

      

  ㅇ HandlerAdapter

      핸들러 매핑으로 선택한 Controller/핸들러를 DispatcherServlet이 호출할 때 사용하는 어댑터이다.

      Controller의 타입에는 제한이 없으며, Controller 호출 방법은 타입에 따라 다르기 때문에 Controller를 결정했다고

      해도 호출 방법은 DispatcherServlet이 알 길이 없다. 

      그래서 Controller 타입을 지원하는 HandlerAdpater가 필요하다.


  ㅇ ViewResolver

      뷰 리졸버는 Controller가 리턴한 뷰 이름을 참고해서 적절한 뷰 오브젝트를 찾아주는 로직을 가진 전략 오브젝트 이다.

      default로 등록된 InternalResourceViewResolver는 JSP나 서블릿 같이 RequestDispatcher에 의해 

      포워딩될 수 있는 리소스를 뷰로 사용하게 해준다.



어느정도 MVC를 알았보았으니 이론은 요정도까쥐만 해보고 재밌는 실습을 한번 해보도록 하겠습니다.

앞으로 우리가 할 것은 MVC를 구축해보는 것 입니다.

그렇다면 시나리오를 하나 생각해보죠!

현재 View는 있고..View에서 어떤것을 클릭! 같은 이벤트를 발생했을 때 즉, 클라이언트에서 요청을 하는 것 이겠죵~

중요한 것은 해당 컨트롤러를 찾게 되어지고 컨트롤러에서 받는 파라미터 처리, MVC처리 후 리턴 처리, View에서는 어떻게 처리가 되어지는지가 중요 할 것 같네요.


4번째 강좌를 보시면 컨트롤러 메소드 파라미에 대해서 간단히 설명을 하였습니다.

나중에 Jquery grid를 사용해야하니 Json통신을 한번 해보겠습니다.(조금 더 뒤에!)

그전에 가장 간단한 @RequestParam도 한번 써보겠습니다. ㅎㅎ 


개발은 검색 페이지 화면을 가지고 해보겠습니다.


결과적으로 검색어를 "박태하하하하하하"를 넣으시고 검색 버튼을 눌렀을 경우에..



아래와 같이 검색결과 페이지로 가는 내용 입니다. 킁; 한글이 깨지네요 ㅋㅋㅋㅋㅋㅋ;


암튼..한글깨짐은 우선 무시하고! 중요한 mvc를 알아보겠습니다. 하하^0^;


구조는 아래와 같습니다. controller를 하나 만들어주시고! jsp파일 또한 하나 만들어줍니다.




컨트롤러 소스는 아래와 같습니다.  


중요하게 봐야 할 부분은 @RequestParam쪽 입니다. 또한 Model~~~:D


간단히 설명을 하자면! 검색어를 넣고 버튼을 클릭 하였을 경우! Client 

즉, JSP단에서 값이 넘어오게 되어지며, 그 값은 searchInput인 String searchKeyword에 담기게 되어집니다.

그 값을 model에 담게 되죵! 그렇게 담긴 값은 searchResult.jsp에서 사용하게 되어집니다! 굳~!


어떤식으로 searchResult.jsp에서 가져다가 사용하는지 알아보겠습니다.

소스는 다음과 같습니다. 


 

위와 같이 ${searchKeyword}  방식으로 값을 가져올 수 있습니다.


다음으로는 ModelAndView객체로 한번 해볼까요? 이번에는 로그인을 가지고 한번 해보겠습니다.

결과는 다음과 같습니다. 아래와 같이 " Do you want to login? "이라는 문구를 login.jsp에 넘겨서 찍어보겠습니다.



우선 controller쪽을 보겠습니다. 아래와 같이 리턴을 ModelAndView로 넘겨줍니다.

위에 제대로 이해하셨다면 당근 DispacherServlet으로 넘겨준다는 것을 이해했을 것 입니다.

mv.setViewName("login"); 이녀석도 login.jsp임을 알수 있습니다.

mv.addObjet(""); 이녀석은 message에다가 해당 String값을 넣어주는 것 입니다. Good~



이제 UI쪽 소스를 보겠습니다. 위와 마찬가지로 ${ } 를 사용하여 찍어줍니다.






요기까지~~MVC에 대해서 알아보았습니다.

@ModelAttribute는 아래의 내용처럼 DTO(VO)의 프로퍼티에 요청 파라미터를 바인딩해서 사용한다고 합니다.


참고 : 2014/02/05 - [OpenSource/Spring 강좌] - [Ace-T의 Spring강좌] Step 04. Spring @MVC 분석-01  의 내용입니다.

요청 파라미터를 메소드 파라미터에서 1:1로 받으면 @RequestParam이고,

 도메인 오브젝트나 DTO, VO의 프로퍼티에 요청 파라미터를 바인딩해서 한번에 받으면 @ModelAttribute라고 볼 수 있다.

 ex) @RequestMapping("/acet/search")

         public String search(@ModelAttribute UserSearch  userSearch){

            List<User> list = userService.search(userSearch);

            model.addAttribute("userList", list);

              ..................

        }



다음 시간에는 @ModelAttribute와 Json 통신에 대해서 알아보도록 하겠습니다. 


Json 통신은 인기있다죠잉~



    - 일단 END -


<< 참고 링크 >>


2014/05/05 - [OpenSource/Spring 강좌] - [Ace-T의 Spring강좌] Step 05. Spring @MVC 분석-02


2014/02/05 - [OpenSource/Spring 강좌] - [Ace-T의 Spring강좌] Step 04. Spring @MVC 분석-01


2013/12/04 - [OpenSource/Spring 강좌] - [Ace-T의 Spring강좌] Step 03. Spring 환경 구축 하기(was)


2013/11/05 - [OpenSource/Spring 강좌] - [Ace-T의 Spring강좌] Step 02. Spring 환경 구축 하기(Maven+Spring Project)


2013/11/03 - [OpenSource/Spring 강좌] - [Ace-T의 Spring강좌] Step 01. Spring 환경 구축 하기(Eclipse+Jdk)

저작자 표시 비영리 변경 금지
신고

acet 박태하가 추천하는 readtrend 추천글!

설정

트랙백

댓글

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

[Ace-T의 Spring강좌] Step 04. Spring @MVC 분석-01

OpenSource/Spring 강좌 2014.02.05 01:32
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T

[Ace-T의 Spring강좌]

   Step 04. Spring @MVC 만들기>>


<< 목표 환경 >>

1) Eclipse(done)

2) PostgreSQL

3) Apache Tomcat or JBoss

4) JUnit(done)

5) SpringFramework(done)

6) JDK 6.0(done)

 


2013/11/03 - [OpenSource/Spring 강좌] - [Ace-T의 Spring강좌] Step 01. Spring 환경 구축 하기(Eclipse+Jdk)


2013/11/05 - [OpenSource/Spring 강좌] - [Ace-T의 Spring강좌] Step 02. Spring 환경 구축 하기(Maven+Spring Project)


2013/12/04 - [OpenSource/Spring 강좌] - [Ace-T의 Spring강좌] Step 03. Spring 환경 구축 하기(was)


 Step 03. Spring 환경 구축 하기(was)에서 환경을 구축해보았습니다.

이제는 mvc에 대해서 알아보도록 하겠습니다^^

우선 spring에서 자동으로 만들어준 소스를 가지고 상태여야 한다.(step 3 을 참고!!)

그 소스에 대해서 조금 간단히 살펴 보겠습니다~

이 글에서는 일명 @MVC를 토대로 합니다.(즉, 어노테이션 기반 MVC이죵!) 

그리고 오늘 학습을 해야 할것은 HomeController.java의 내용에 있는 어노테이션들 입니다.

@RequestMapping, @Controller

 

HomeController.java      

package kr.pe.acet;

import java.text.DateFormat;
import java.util.Date;
import java.util.Locale;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;

/**
 * Handles requests for the application home page.
 */
@Controller
public class HomeController {
 
 private static final Logger logger = LoggerFactory.getLogger(HomeController.class);
 
 /**
  * Simply selects the home view to render by returning its name.
  */
 @RequestMapping(value = "/", method = RequestMethod.GET)
 public String home(Locale locale, Model model) {
  logger.info("Welcome home! The client locale is {}.", locale);
  
  Date date = new Date();
  DateFormat dateFormat = DateFormat.getDateTimeInstance(DateFormat.LONG, DateFormat.LONG, locale);
  
  String formattedDate = dateFormat.format(date);
  
  model.addAttribute("serverTime", formattedDate );
  
  return "home";
 }
 
}

 

하지만 우선~~~!! Controller의 메소드 파라미터를 보도록 하겠지만...

아래의 Controller의 메소드 파라미터 블라블라를 보기전에 아래의 MVC의 주요 구성요소와 MVC패턴에 

대해서먼저 학습하면 좋을 것 같습니다.

2012/11/09 - [OpenSource/Spring MVC] - Spring MVC의 주요 구성요소


이제 아래를 학습하여 보자!

 @Controller 의 메소드 파라미터로 올 수 있는 것들!(참고 : 토비님 책3.1v 볼률2, 486p~)

 파라미터(Parameter)

 간단 설명(simple contents)

 HttpServletRequest,

 HttpServletResponse

 서블릿 관련~

 HttpSession

 서블릿 관련~

 WebRequest,

NativeWebRequest

 HttpServletRequest의 요청정보를 대부분 그대로 갖고 있는, 서블릿 API에

 종속적이지 않은 오브젝트 타입이다.(서블릿과 포틀릿 환경 양쪽에 모두 적용

 가능한 범용적인 핸들러 인터셉터를 만들 때 활용하기 위해 만들어졌다.

Locale

 java.util.Locale 타입으로 DispatcherServlet의 지역정보 리졸버(Locale

 Resolver)가 결정한 Locale 오브젝트를 받을 수 있다.

 Locale은 예를들어 ko_KR, jp_JP(?) 암튼 한국어, 일본어, 영어 등등 이라고

 보면  된다.

InputStream, Reader

 HttpServletRequest의 getInputStream()을 통해서 받을 수 있는 콘텐트 스트림

 또는 Reader 타입 오브젝트를 제공 받을 수 있다.

OutputStream, Writer

 HttpServletRequest의 getIOutputStream()을 통해서 받을 수 있는 콘텐트 스트림

 또는 Writer 타입 오브젝트를 제공 받을 수 있다.

@PathVariable

 @RequestMapping의 URL에 {}로 들어가는 패스 변수(path variable)를 받는다.

 http://acet.pe.kr/post/?id=10 이라고 하는걸 http://acet.pe.kr/post/10 으로

 만들 수 있다.

 ex) @RequestMapping("/post/{id}")

      public String view(@PathVariable

@RequestParam

 public String view(@RequestParam("id") int id){....}

@CookieValue

 HTTP요청과 함께 전달된 쿠키 값을 메소드 파라미터에 넣어주도록

 @CookieValue를 사용 할 수 있다.

@RequestHeader

 요청 헤더정보를 메소드 파라미터에 넣어주는 어노테이션이다. 

 헤더정보에 있는 Server정보, Content-Type등의 정보를 이용하여 어디에서 접근

 하는지 알아내서 view를 다르게 해준다던지 하는 것들을 구현 할 수 가 있다. 

Map, Model, ModelMap

 다른 어노테이션이 붙어있지 않다면

 @ModelAttribute

 요청 파라미터를 메소드 파라미터에서 1:1로 받으면 @RequestParam이고,

 도메인 오브젝트나 DTO, VO의 프로퍼티에 요청 파라미터를 바인딩해서 한번에 받으면 @ModelAttribute라고 볼 수 있다.

 ex) @RequestMapping("/acet/search")

         public String search(@ModelAttribute UserSearch  userSearch){

            List<User> list = userService.search(userSearch);

            model.addAttribute("userList", list);

              ..................

        }

Errors, BindingResult 

 변환작업 시 오류가 있을 때 @ModelAttribute를 사용 했을 때는 @RequestParam과는 달리 HTTP 400 이 발생하지 않고 작업은 계속 진행 되어지며, 단지 타입 변환 중에 발생한 예외가 BindException 타입의 오브젝트에 담겨서 컨트롤러로 전달 된다. 즉, 예외처리에 대한 기회를 주어야 하므로

 org.springframework.validation.Errors or org.springframework.validation.

BindingResult 타입의 파라미터를 같이 사용 한다.

 ex) @RequestMapping(value="add", method=RequestMethod.POST)

      public String add(@ModelAttribute User user, BindingResult bindingResult)      { ................... }

 BindingResult 대신 Errors를 사용해도 되며, 사용시 주의 사항으로는 반드시

 @ModelAttribute 뒤에 나와야 한다.@ModelAttribute 검증작업에서 나온 오류만을

 전달하기 때문이다. 

 SessionStatus

 컨트롤러가 제공하는 기능 중에 모델 오브젝트를 세션에 저장했다가 다음 페이지

 에서 다시 활용하게 해주는 기능이 있다. 

 org.springframework.web.bind.support.SessionStatus 오브젝트이며,

 필요없어지면 확실하게 제거해줘야 한다.

 @RequestBody

 Http 요청의 본문(body) 부분이 그대로 전달 된다.

 일반적인 GET/POST의 요청 파라미터라면 사용 할 일이 없다. 

 XML이나 JSON 기반의 메시지를 사용하는 경우에는 이 방법이 매우 유용하다.

 또한 메시지컨버터가 필요하다! ㅎㅎ 

 @Value

 SpEL을 이용해 클래스의 상수를 읽어오거나 특정 메소드를 호출한 결과 값, 조건식 등을 넣을 수 있다.

 ex) @RequestMapping(...)

 public String hello(@Value("#{systemProperties['os.name']}") String osName){...} 필드 주입이라는 것도 있다.

 @Valid

 @Valid는 JSR-303의 빈 검증기를 이용해서 모델 오브젝트를 검증하도록 지시하는지시자다. 

서버 Valid는 토비 책 뒤편에 보면 나오며, @Validate도 있다!~

 

많은 것들이 있네요..하하;

하지만 우리의 소스에서는 아래와 같이 Locale과 Map, Model, ModelMap 중 Model이 쓰였습니다. ㅋㅋ

  public String home(Locale locale, Model model) {


Controller 소스는 매우 간단합니다.  시간을 구해서 해당 View에다가 줘서 찍어주는게 끝이네요^^;

   model.addAttribute("serverTime", formattedDate );  

  return "home";


※ Model Interface (http://docs.spring.io/spring/docs/3.2.x/javadoc-api/ 참조 하시면 됩니다.)

org.springframework.ui

  Interface Model

Model addAttribute(String name, Object value)

value 객체를 name 이름으로 추가 

Model addAttribute(Object value)

value를 추가. value의 패키지 이름을 제외한 단순 클래스 이름을 모델 이름으로 사용(첫 글자는 소문자). value가 배열이거나 콜렉션인 경우 첫 번째 원소의 클래스 이름 뒤에 "List"를 붙인 걸 모델 이름으로 사용(첫 글자는 소문자)

Model addAllAttributes(Collection<?> values)

addAttribute(Object value) 메소드를 이용해서 콜렌션에 포함된 객체들을 차례대로 추가

Model addAllAttributes(Map<String, ?>, attributes)

Map에 포함된 <키, 값>에 대해 키를 모델 이름으로 사용해서 값을 모델로 추가

Model mergeAttributes(Map<String, ?>, attributes>

Map에 포함된 <키, 값>을 현재 모델에 추가. 단 키와 동일한 이름을 갖는 모델 객체가 존재하지 않는 경우에만 추가

boolean containsAttributes(String name)

지정한 이름의 모델 객체를 포함하고 있는 경우 true 리턴


     위의 model에서 시간을 serverTime에다가 넣어주면 그 model은 home.jsp에 전달이 되어진다.

     즉, View단, home.jsp(src/main/webapp/WEB-INF/views/home.jsp)를 보면 아래와 같습니다.

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

<%@ page session="false" %>

<html>

<head>

<title>Home</title>

</head>

<body>

<h1>

Hello world!  

</h1>


<P>  The time on the server is ${serverTime}. </P>

</body>

</html>



     << 결과 >>     


아래의 주소(http://localhost:8080/)대로 치면 아래처럼 결과가 나오지 않는다. 그 이유는 Step 03 강좌에서도 설명 하였듯이 Context root 가 다른걸로 잡혀있기 때문이다.

그러므로 tomcat의 context root를 / 로 수정을 해주면 된다.

자세한 설명은  

2013/12/04 - [OpenSource/Spring 강좌] - [Ace-T의 Spring강좌] Step 03. Spring 환경 구축 하기(was)


또는 아래의 동영상을 참고 하길 바랍니다^^;; - (단, STS 기반 입니다~!)

(동영상이 구리긴하네요...720 고화질로 보셔야 합니다~~)



쫘잔~~아래의 결과가 나오시나요?? ㅎㅎㅎ

[Locale이 잘 안맞는지...깨져서 나온다 ㅋㅋ; 일단 PASS~~~]


 Model addAttribute(String name, Object value)로 인해서 시간이 name에 binding 되어지고, ${serverTime}으로 찍혀지게 된다.  스트럿츠나 jsp로 코드를 짜던 시절에서는 request로 view단에 넘겨주고는 하였다.

위의 내용을 정확히 알기 위해서는 Spring MVC 패턴, WEB.xml(was꺼 아니죠~) 을 알아야 한다.

다시 한번~링크!!

2012/11/09 - [OpenSource/Spring MVC] - Spring MVC의 주요 구성요소 

2012/11/09 - [OpenSource/Spring MVC] - 웹??? web.xml은 알고 하자!!


Web 브라우저에서 URL 들어오면, WEB.xml에 설정 해 놓은 DispatcherServlet에 전달 되어지고, 

url-mapping에 의해 mapping되어진 Controller를 찾고 해당하는 method부터 시작이 되어진다! 두둥~


옛날 jsp 시절에는 view단에서  <%= request.getParameter("name") %>를 썼었다. ㅋㅋ;




 음...조금 더 디테일하게 써보려고 했는데....새벽 1시간 넘었네요..ㅠ.ㅠ..

 독감이 걸린 상태라..쿨럭 쿨럭~ 이번 강좌는 여기까지 써야겠네요..하하;

 조금이나마 도움이 되셨으면 좋겠네요^-^

 건강이 제일 큰 재산 입니다. 건강하세요~~~~


5번째 강좌에서는 조금 더 자세하게 Spring MVC에 대해서 학습 하도록 하겠습니다^-^

언젠가는...Mybatis도 연동하는 날이 오겄져 뭐~ㅋㅋㅋㅋ


     - to be continue... by Ace-T -

저작자 표시 비영리 변경 금지
신고

acet 박태하가 추천하는 readtrend 추천글!

설정

트랙백

댓글

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

스프링시큐리티 시작하기 - XML을 통한 인증 예제(묻지마 따라하기!)

OpenSource/Spring Security 2014.01.14 14:42
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T


spring-security 시작하기(묻지마 따라하기!)

1) 설정

2) 테스트

3) 참고문서

4) Tip

5) 같이 보기

 

본 블로그에서 기본프로젝트를 만드는 스프링프레임워크 강좌의 소스를 기반으로 테스트 하였습니다.

고로 web이 구축되어있는 상태에서 spring-security를 구축하는 내용 입니다.^^;


<< 설정 >>

maven 3

Eclipse Indigo

jdk 1.6

springframework 3.1

spring-security 3.1.3.Release 



3.1.0 version은 Bug 있음. 

    - 참고 URL : http://stackoverflow.com/questions/10216563/spring-security-error-

                       creating-bean-org-springframework-security-filterchains

    - 오류내역 : error creating bean with name org.springframework.security.filterchains' 

                     initialization of bean failed


1) pom.xml(해당 jar 가져오기)

 <dependency>

<groupId>org.springframework.security</groupId>

<artifactId>spring-security-core</artifactId>

<version>3.1.3.RELEASE</version>

</dependency>

<dependency>

<groupId>org.springframework.security</groupId>

<artifactId>spring-security-taglibs</artifactId>

<version>3.1.3.RELEASE</version>

</dependency>

<dependency>

<groupId>org.springframework.security</groupId>

<artifactId>spring-security-config</artifactId>

<version>3.1.3.RELEASE</version>

</dependency> 


2) web.xml

<!-- Spring Security Filter Proxy -->

<filter>

<filter-name>springSecurityFilterChain</filter-name>

<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>

</filter>

<filter-mapping>

<filter-name>springSecurityFilterChain</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>


※ 아래의 설정으로 context-security.xml 을 가져온다.

<!-- Context definition -->

<context-param>

<param-name>contextConfigLocation</param-name>

<param-value>classpath:spring/context/*.xml</param-value>

</context-param>



3) context-security.xml

<beans:beans xmlns="http://www.springframework.org/schema/security"

xmlns:beans="http://www.springframework.org/schema/beans" 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.1.xsd

http://www.springframework.org/schema/security

http://www.springframework.org/schema/security/spring-security-3.1.xsd">

<http auto-config="true">

<intercept-url pattern="/*" access="ROLE_USER" />

</http>

<authentication-manager alias="authenticationManager">

<authentication-provider>

<user-service>

<user authorities="ROLE_USER" name="acet" password="1"/>

</user-service>

</authentication-provider>

</authentication-manager>

</beans:beans>

 

 

심각: Exception starting filter springSecurityFilterChain 관련 bean이 생성되지 않았다는 오류가 날 수가 있다. 제대로 contextConfigLocation 이 설정되지 않았을 가능성이 있다.


 


<< 테스트 >>

was 기동 후 아래의 URL로 접근하면..Login 화면이 나오게 된다.

http://localhost:8080/acet/spring_security_login

 

 


<<  참고문서 >>

SpringSecurity3 - 도마뱀그림 있는 책ㅋㅋ;


<< Tip >>

SpringSecurity version을 조심! 3.1사용 시 3.1.3 Realse를 사용하자!


<< 같이 보기>>

2013/02/13 - [OpenSource/Spring Security] - 먼저 알아두면 좋은스프링 시큐리티 용어


2013/05/19 - [OpenSource/Spring Security] - 스프링 시큐리티 시작하기 Lesson 01


2013/08/12 - [OpenSource/Spring Security] - 스프링시큐리티 - DelegatingFilterProxy


2013/08/17 - [OpenSource/Spring Security] - 스프링시큐리티 - Filter Chain




                                            - END -





저작자 표시 비영리 변경 금지
신고

acet 박태하가 추천하는 readtrend 추천글!

설정

트랙백

댓글

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

[다섯번째] Spring 사내 스터디

Study/Study group 2012.12.03 13:58
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T

참고 URL :

2012/10/23 - [Study/Study group] - [첫번째] Spring 사내 스터디

2012/10/31 - [Study/Study group] - [두번째] Spring 사내 스터디

2012/11/12 - [Study/Study group] - [세번째] Spring 사내 스터디

2012/11/26 - [Study/Study group] - [네번째] Spring 사내 스터디



 



- 스터디 범위
  용수철 1기
  토비 vol 2, 1장

  용수철 2기
  토비 vol1. 1장


Review

1장. IoC 컨테이너와 DI

스프링 애플리케이션은 오브젝트의 생성과 관계설정, 사용, 제거 등의 작업을 애플리케이션 코드 대신
독립된 컨테이나거 담당한다. 이를 컨테이너가 코드 대신 오브젝트에 대한 제어권을 갖고 있다고 해서
IoC라고 부른다. 그래서 스프링 컨테이너를 IoC컨테이너라고도 한다.

Think :

더보기





또한, 스프링에선 IoC를 담당하는 컨테이너를 빈 팩토리 또는 애플리케이션 컨텍스트라고 부르기도 한다.
"BeanFactory와 ApplicationContext는 각각 인터페이스로 정의 되어있다."
그래서 실제로 스프링 컨테이너 또는 IoC컨테이너라고 말하는 것은 바로 이 ApplicationContext 인터페이스를 구현한 클래스의 오브젝트이다.

ex) StaticApplicationContext ac = new StaticApplicationContext();
위의 코드는 IoC 컨테이너가 만들어진 것인가??     

더보기


IoC가 동작하려면?

더보기


스프링의 설정 메타정보는 XML이 아니다.
스프링의 설정 메타정보는 BeanDefinition 인터페이스로 표현되는 순수한 추상 정보이다.
스프링의 메타정보는 특정한 파일 포맷이나 형식에 제한되거나 종속되지 않는다.
대신 XML 이든 소스코드 애노테이션이든 자바코드이든 프로퍼티 파일이든 상관 없이 BeanDefinition으로
정의되는 스프링의 설정 메타정보의 내용을 표현한 것이 있다면 무엇이든 사용 가능 하다.
단, 원본의 포맷과 구조, 자료의 특성에 맞게 읽어와 BeanDefinition 오브젝트로 변환해주는 BeanDefinitionReader 가 있으면 된다. BeanDefinitionReader도 인터페이스이다.^-^good~

[그림1] IoC 컨테이너를 통해 애플리케이션이 만들어지는 방식


일반적으로 설정 메타정보는 XML파일이나 애노테이션 같은 외부 리소스를 전용리더가 읽어서 BeanDefinition 메타정보를 생설 할 수 있다.

위의 그림에서 메타정보 리소스(XML, 애노테이션, 자바코드) 이다. 아래의 그림2를 다시 보도록 하자.

[그림2] 컨테이너가 활용하는 빈 설정 메타정보



IoC 컨테이너 계층구조
 - 부모, 자식(계층 구조)
 - 빈 검색 시 1) 자기자신 2) 부모 애플리케이션의 빈까지 모두 검색
    단, 자식 컨텍스트에게는 요청하지 않음.(검색 X)

[그림3] 스프링 웹애플리케이션의 다양한 구성 방법


역시나 계층구조로 되어있다. 왜 이렇게 계층구조로 만들까?

더보기




Mr. Gong> servlet 2.5
 









저작자 표시 비영리 변경 금지
신고

acet 박태하가 추천하는 readtrend 추천글!

설정

트랙백

댓글

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

[네번째] Spring 사내 스터디

Study/Study group 2012.11.26 19:00
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
스터디 인원 대거 합류..!!
1~2장 : 백, 박, 석, 김, 강
6~7장 : 공, 박, 권, 김, 차(결석)

2012/10/23 - [Study/Study group] - [첫번째] Spring 사내 스터디

2012/10/31 - [Study/Study group] - [두번째] Spring 사내 스터디

2012/11/12 - [Study/Study group] - [세번째] Spring 사내 스터디


[스프링 스터디 4번째]

토비 vol 1, 6~7장 (분량 대략 300페이지)

1) AOP - IoC/DI / 서비스추상화와 더불어 스프링의 3대 기반 기술 중 하나 이다.

2) 목 프레임워크 : 그중에서도 Mockito라는 프레임워크는 사용하기도 편리하고, 코드도 직관적이라
                        최근 많은 인기를 얻고 있음.
3) 트랜젝션
    - 핵심기능, 부가기능 : 부가기능과 핵심기능의 분리 => 프록시

4) 프록시 : 클라이언트가 사용하려고 하는 실제 대상인 것처럼 위장해서 클라이언트의 요청을
              받아주는 것을 대리자, 대리인과 같은 역할을 한다고 해서 프록시(proxy)라고 부른다.
최종적으로 요청을 위임받아 처리하는 실제 오브젝트를 타깃(target) 또는 실체(subject) 라고 부른다.

ex) 프록시 생성
Hello proxiedHello = (Hello)Proxy.newProxyInstance(
    getClass().getClassLoader(),
     -> 동적으로 생성되는 다이내믹 프록시 클래스의 로딩에 사용할 클래스 로더

    new Class[] {Hello.class}, <- 구현할 인터페이스
    new UppercaseHandler(new HelloTarget()))); -> 부가기능과 위임코드를 담은 핸들러

토비 1 - 431p
     클라이언트  ------------->        프록시  ------------->       타깃 


"데코레이터 패턴" : 인터페이스를 통해 위임, 프록시를 사용
"프록시 패턴" : 클라이언트에게 타깃에 대한 레퍼런스를 넘겨야하는데, 실제 타깃 오브젝트는 만드는
                 대신 프록시를 넘겨주는 것이다. 프록시의 메소드를 통해 타깃을 사용하려고 시도하면,
                 그때 프록시가 타깃 오브젝트를 생성하고 요청을 위임해주는 식이다.



interface에 선언된 메소드들을 쓰지도 않는 것들은 구현 할 필요가 없다.




"다이내믹 프록시" : 타깃의 인터페이스와 같은 타입으로 만들어진다.
                         + 리플렉션 방식(Java.lang.reflect)
 - 프록시 기능 : 타깃과 같은 메소드를 구현하고 있다가 메소드가 호출되면 타깃 오브젝트로 위임한다.
                 지정된 요청에 대해서는 부가기능을 수행 한다.
 - 리플렉션 : 자바의 코드 자체를 추상화해서 접근하도록 만든 것이다.
    ex) String의 length() 메소드라고 하면
        1)  Method lengthMethod = String.class.getMethod("length");
        2) invoke() : 메소드를 실행시킬 대상 오브젝트와 파라미터 목록을 받아서 메소드를
                         호출한 뒤에 그 결과를 Object  타입으로 돌려준다.




 - 어드바이스(Advice) : 타깃 오브젝트에 적용하는 부가기능을 담은 오브젝트
 - 포인트 컷(PointCut) : 부가기능 적용 대상 메소드 선정 방법

      <1> 프록시는 클라이언트로부터 요청을 받으면 먼저 포인트컷에게 부가기능을 부여할 메소드를
            확인 해달라고 요청한다.
      <2>확인 받은 뒤 어드바이스를 호출 한다.
 -  어드바이저 : 여러개의 어드바이스와 포인터컷이 추가 될 수 있기 때문에 따로 등록 시
                     어떤 어드바이스(부가기능)에 대해 어떤 포인트컷(메소드 선정)을 적용 할지
                     애매해진다.
                     그래서 어드바이스와 포인트컷을 묶은 오브젝트를 어드바이저라고 부른다.
                     어드바이저 = 포인트컷(메소드 선정 알고리즘)+어드바이스(부가기능)



"빈 후처리기" : 자동프록시 생성
 1) DefaultAdvisorAutoProxyCreator 빈 후처리기가 등록 되어있으면
 2) 스프링은 빈 오브젝트를 만들 때마다 후처리기에게 빈을 보낸다.
 3) DefaultAdvisorAutoProxyCreator는 빈으로 등록된 모든 어드바이저 내의 포인트컷을 이용해
     전달 받은 빈이 프록시 적용 대상인지 확인 한다.
 4) 프록시 적용 대상이면 내장된 프록시 생성기에게 현재 빈에 대한 프록시를 만들게 하고, 만들어진
     프록시에 어드바이저를 연결
해준다.
 5) 빈 후처리기는프록시가 생성되면 원래 컨테이너가 전달해준 빈 오브젝트 대신
     프록시 오브젝트를 컨테이너에게 돌려준다.



"확장된 포인트컷" : 사실..한가지가 더 있었음..--;;
포인트컷은 클래스 필터와 메소드 매처 2가지를 돌려주는 메소드를 가지고 있다.
public interface Pointcut{
    ClassFilter getClassFilter();  -> 프록시를 적용할 클래스인지 확인
    MethodMatcher getMethodMatcher(); -> 어드바이스를 적용할 메소드인지 확인
}



"포인트컷 표현식(pointcut expression)"
복잡함, 세밀함 -> class, method 선정 ==> pointcut expression


AOP란? Aspect Oriented Programming(애스팩트 지향 프로그래밍)


위처럼 핵심적인 기능에서 부가적인 기능을 분리해서 애스펙트라는 독특한 모듈로 만들어서 설계하고 개발하는 방법.
AOP는 OOP를 돕는 보조적인 기술이지 OOP를 대체하는 새로운 개념은 아님.

"AspectJ" : 프록시 처럼 간접적인 방법이 아닌 타깃 오브젝트를 뜯어고쳐서 부가기능을
                직접 넣어주는 직접적인 방법
                즉, 컴파일된 타깃의 클래스 파일 자체를 수정하거나 클래스가 JVM에 로딩되는 시점을
                가로채서 바이트코드를 조작하는 방법   

512p~555p 

 - 끝 -

AOP : cross cutting concern
1) 로그
2) 에러처리,
3) 트랜젝션 처리
 - select (read only)
    insert*
    update*
    delete
    (CUD)
정책에 따라 사전에 해줘야 함.
AOP 적용 시 명명규칙이 중요 함. 레벨(Service, Fasade Layer)결정- 최상위 레벨을 확인
서비스 단위는 업무적으로 각기 다르다. 또는 서로 연관이 있을 수 도 있다.

트랜젝션 전파
 - 특정 메소드 제외

Q) 각각의 서비스도 class 프록시로 구분이 가능 할 꺼 같음. - 상위가 있을 경우 한단계 UP
    구분 가능.






저작자 표시 비영리 변경 금지
신고

acet 박태하가 추천하는 readtrend 추천글!

설정

트랙백

댓글

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

[첫번째] Spring 사내 스터디

Study/Study group 2012.10.23 00:45
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
2012.10.23(수) 첫 스프링 스터디!!

자! 스프링..처음 공부한다고 한다면..무엇을 해야하나?? 생각해보자! 단. 3초간..

음.....
움......
um......




고민을 끝냈다면! 실천해보자^-^ Right Now~!!

1. 스프링을 테스트 할 수 있는 환경을 만들자!^-^good~
2. 레퍼런스와 Api를 적극 참조 하자!(현재 레퍼런스 3.1을 외부 스터디(자바카페+KSUG)를 하고 있으니!
   스터디 범위에 맞게 공부해 나가자^-^/
3. 적극 테스트를 실전 환경에서 해보자!





자~~이제 신나고 재밌는 Spring이라는 녀석을 만나러 가보자^-^~~oh yeh~~^-^

제 1장. 스프링이란 무엇인가?
   간략히 말해 자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크

- 스프링을 MVC 프레임워크 또는 JDBC/ORM 지원 프레임워크라고 생각하는 것은 스프링이 다루는
  일부 영역만 봤기 때문이다.(이런!!!ㅠㅠ)

- 또, 스프링을 IoC/DI 프레임워크나 AOP 툴이라고 보는 이유는 스프링이 제공하는 핵심 기술에만
   주목 했기 때문이다.(OMG~~)

DI의 기본 아이디어는 유연하게 확장 가능한 오브젝트를 만드어두고 그 관계는 외부에서 다이나믹하게 설정 해준다는 것이다.


스프링 애플리케이션은 POJO를 이용해서 만든 애플리케이션 코드와, POJO가 어떻게 관계를 맺고 동작하는지를 정의 해놓은 설계정보로 구분 된다.

스프링의 주요기술인 IoC/DI, AOP와 PSA(Portable Service Abstraction는 애플리케이션을 POJO로 개발 할 수 있게 해주는 가능 기술이라고 불린다.

여기에서..POJO 포조 하는데 도데체 포조란 무엇이라는 말인가?????
막 퍼죠? (퍽..죄송합니다..@.,@;;)

POJO란 무엇인가??
POJO는 Plain Old Java Object이다!!
마틴 파울러가 2000년에 컨퍼런스 발표를 준비하다가 만들어낸 용어라고 한다.
단순한 자바오브젝트를 사용한다는 것이 아니라, POJO방식의 기술을 사용합니다~라고
하는 그럴싸하다.

POJO의 조건
평범하게 자바오브젝트라고 할 수 있지만
적어도 다은 세가지를 충족 해야 POJO라고 불릴 수 있다.
1. 특정 규약에 종속되지 않는다.
   : 규약 따위에 종속되지 않아야 하고, 객체 지향 설계의 자유로운 적용이 가능한 오브젝트여야만
     POJO라고 불릴 수 있다.
2. 특정 환경에 종속되지 않는다.
  : 환경에 독립적이여야 한다.

스프링에는 POJO 프로그래밍을 손쉽게 할 수 있도록 지원하는 세가지 가능 기술을 제공한다.
(IoC/DI, AOP, PSA)

참고 문헌 : 토비의 스프링3.1 8장 





저작자 표시 비영리 변경 금지
신고

'Study > Study group' 카테고리의 다른 글

[KSUG+Java cafe] 스프링 스터디  (0) 2012.11.10
[두번째] Spring 사내 스터디  (0) 2012.10.31
[첫번째] Spring 사내 스터디  (2) 2012.10.23
Google Developers Korea  (0) 2012.08.24
스터디 모임 소개^-^  (0) 2012.08.21
자바 마지막^^  (0) 2012.03.22

acet 박태하가 추천하는 readtrend 추천글!

설정

트랙백

댓글

  • er1ca 2012.10.26 15:54 신고 답글 | 수정/삭제 | ADDR

    으헝 !!!!!!!!!!!!!!=ㅁ=............ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

표준 프레임워크 오픈커뮤니티 26차 정기기술세미나^-^

Study/Seminar 2012.10.08 13:15
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
표준 프레임워크 오픈커뮤니티 26차 정기기술세미나를 한다고 한다.
토비님이 발표하시는듯~이번에 토비의 스프링3.1이 나왔다고 하던데..
스프링프레임워크의 선두두자! 토비님 지금 만나러갑니다. ㅋㅋ
시간은~!! 10월10일 19시30분~21시30분~!! ㄱㄱㄱ

- 참가신청!!은 아래의 URL ^-^
http://open.egovframe.go.kr/projects/notices/event/4935

저작자 표시 비영리 변경 금지
신고

acet 박태하가 추천하는 readtrend 추천글!

설정

트랙백

댓글

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

Spring XML을 이용한 설정

OpenSource/Spring 2012.08.16 17:09
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
스프링의 애플리케이션 컨텍스트는 XML에 담긴 DI정보를 활용 할 수 있다.

DI 정보가 담긴 XML 파일은 <beans>를 루트 엘리먼트로 사용한다.
<beans>는 이름에서도 알 수 있듯이 여러개의 <bean>을 정의 할 수 있다.

아래의 그림처럼 http://acet.pe.kr/120  에서의 @configuration과 @bean을 각 @configuration을 <beans>
@bean을 <bean>이라고 대응해서 생각하면 더 쉬울 것 이다.

[참고 그림]


클래스 설정과 xml설정의 대응항목
   자바 코드 설정정보  XML 설정정보
 빈 설정파일  @Configuration  <beans>
 빈의 이름  @Bean methodName()  <bean id="methodName"
 빈의 클래스  return new BeanClass();  class="a,b,c...BeanClass">

ex) connectionMaker()메소드의 <bean> 태그 전환
@Bean   --------------------------------> <bean
pubilc ConnectionMaker
    connectionMaker(){ -------------------> id="connectionMaker"
         return new DConnectionMaker(); ----> class="springbook...DConnectionMaker" />
    }


※ <property> 태그를 사용해 의존 오브젝트와의 관계를 정의 해보자.
<property> 태그는 name과 ref라는 두개의 애트리뷰트를 갖는다.
name은 애트리뷰트의 이름이다. 이 프로퍼티 이름으로 수정자 메소드를 알 수 있다.
ref는 수정자 메소드를 통해 주입해줄 오브젝트 빈 이름이다.

ex) userDao.setConnectionMaker(connectionMaker()); 를 아래와 비교해보라.
<property name="connectionMaker" ref="connectionMaker" />

<property> tag를 <baen> tag안에 넣어주면 된다.
ex)
     <bean id="userDao" class="springbook.dao.UserDao">
             <property name="connectionMaker" ref="connectionMaker" />
      </bean>

이첨럼 <bean> tag를 이용해 @Bean 메소드를 모두 xml로 변환 했다.
마지막으로 <beans> tag로 감싸주면 된다.
ex)
<beans>
    <bean id="connectionMaker" class="springbook.user.dao.DConnectionMaker" />
    <bean id="userDao" class="springbook.dao.UserDao">
          <property name="connectionMaker" ref="connectionMaker" />
    </bean>
</beans>

※ <property> tag의 name과 ref는 그 의미가 다르므로 이름이 같더라도 어떤 차이가 있는지 구별 할 수 있어야 한다.
name 애트리뷰트DI에 사용할 수정자 메소드의 프로퍼티 이름이며, ref 애트리뷰트주입할 오브젝트를 정의한 빈의 ID(DI 받을 빈을 지정) 이다. 보통 프로퍼티이름과 DI되는 빈의 이름이 같은 경우가 많다.

저작자 표시 비영리 변경 금지
신고

acet 박태하가 추천하는 readtrend 추천글!

설정

트랙백

댓글

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

DI(Dependency Injection)

OpenSource/Spring 2012.08.09 17:06
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T



출처 : 토비의 스프링 3
DI(Dependency Injection) : 의존관계 주입!

배경 : IoC의 너무 넓은 의미=> Spring의 기능, 특징을 한마디로 표현 X => DI 라는 용어를 만듬.

DI는 외부로부터 레퍼런스를 제공받고, 이를 통해 여타 오브젝트와 다이나믹하게 의존관계가 만들어지는 것이 핵심이다.

의존관계 주입은 다음과 같은 세가지 조건을 충족하는 작업을 말한다.
1) 클래스 모델이나 코드에는 런타임 시점의 의존관계가 드러나지 않는다. 그러기 위해서는 인터페이스에만 의존하고 있어야 한다.
2) 런타임 시점의 의존관계는 컨테이너나 팩토리 같은 제3의 존재가 결정한다.
3) 의존관계는 사용할 오브젝트에 대한 레퍼런스를 외부에서 제공(주입) 해줌으로써 만들어진다.

다시 또 말해보면 DI는 자신이 사용할 오브젝트에 대한 선택과 생성 제어권을 외부로 넘기고 자신은 수동적으로 주입받은 오브젝트를 사용한다는 점에서 IoC의 개념에 잘 들어맞는다.

스프링이 제공하는 IoC방법은 의존관계주입(DI)만 있는 것이 아니다.
코드에서는 구체적인 클래스에 의존하지 않고, 런타임 시에 의존관계를 결정한다는 점에서 의존관계 주입과 비슷하지만, 의존관계를 맺는 방법이 외부로부터의 주입이 아니라 스스로 검색을 이용하기 때문에 의존관계 검색(dependeny lookup)이라고 불리는 것도 있다. 의존관계 검색은 자신이 필요로 하는 의존 오브젝트를 능동적으로 찾는다. 물론 자신이 어떤 클래스의 오브젝트를 이용할지 결정하지는 않는다. 그러면 IoC라고 할 수는 없을 것이다. 의존관계 검색은 런타임 시 의존관계를 맺을 오브젝트를 결정하는 것과 오브젝트의 생성작업은 외부 컨테이너에게 IoC로 맡기지만, 이를 가져올 때는 메소드나 생성자를 통한 주입 대신 스스로 컨테이너에게 요청하는 방법을 사용한다.

스프링의 IoC컨테이너인 애플리케이션 컨텍스트는 getBean()이라는 메소드를 제공한다. 바로 이 메소드가 의존관계 검색에 사용 된다.

ex)

public UserDao(){
  AnnotationConfigApplicationContext context =
                                       new AnnotationConfigApplicationContext(DaoFactory.class);

   this.connectionMaker = context.getBean("connectionMaker", ConnectionMaker.class);
}

※ DI를 원하는 오브젝트는 먼저 자기자신이 컨테이너가 관리하는 빈이 돼야 한다는 사실을 잊지 말자.
    스프링의 핵심인 IoC와 DI는 오브젝트의 설계와 생성, 관계 사용에 관한 기술 이다.

의존관계 검색과 의존관계 주입에서의 차이는
   의존관계 검색 방식에서는 검색하는 오브젝트는 자신이 스프링의 빈일 필요가 없다는 점이다.

스프링은 DI를 편하게 사용 할 수 있도록 도와주는 도구이면서 그 자체로 DI를 적극 활용한 프레임워크 이기도 하다. 그래서 스프링을 공부하는 건 DI를 어떻게 활용해야 할지를 공부하는 것이기도 하다.

DI는 생성자 뿐만 아니라 수정자 메소드(setter), 일반메소드(set으로 시작) 등으로도 구현이 가능.
저작자 표시 비영리 변경 금지
신고

acet 박태하가 추천하는 readtrend 추천글!

설정

트랙백

댓글

  • 초보 2013.01.24 03:08 신고 답글 | 수정/삭제 | ADDR

    아래의 의존관계 주입과 검색의 차이점이 잘 이해가 안됩니다.

    의존관계 검색 방식에서는 검색하는 오브젝트는 자신이 스프링의 빈일 필요가 없다는 점이다.

    검색하는 오브젝트는 UserDao이며 UserDao는 빈으로 등록되어야 한다는 뜻인가요?

    답변 부탁드립니다.

    • Favicon of http://acet.pe.kr BlogIcon String Ace-T 2013.01.24 16:27 신고 수정/삭제

      네 안녕하세요^^
      문의 하신 "의존관계 검색 방식에서는 검색하는 오브젝트는 자신이 스프링의 빈일 필요가 없다는 점이다" 이 문구만으로는 조금 이해하시기 어려우실꺼라 생각이 드네요^^;; 제가 더 자세하게 기술을 했어야 했는데 너무 포인트만 적어놨네요;

      위의 문구를 이해하실려면
      더 상단에 적힌 3개의 조건을 이해 하셔야 합니다.
      의존관계 주입은 다음과 같은 세가지 조건을 충족하는 작업을 말한다.
      1) 클래스 모델이나 코드에는 런타임 시점의 의존관계가 드러나지 않는다. 그러기 위해서는 인터페이스에만 의존하고 있어야 한다.
      2) 런타임 시점의 의존관계는 컨테이너나 팩토리 같은 제3의 존재가 결정한다.
      3) 의존관계는 사용할 오브젝트에 대한 레퍼런스를 외부에서 제공(주입) 해줌으로써 만들어진다.

      3가지 내용은 토비1권을 보시면 됩니다.
      또한 지금 위의 3가지는 의존관계에 대해서 강조 하고 있습니다.
      다시 말씀 드리면 DI / DL의 큰 차이는 "의존관계"가
      가장 큰 차이라고 할 수 있겠네요
      DI는 서로 의존 관계가 있죠! 어떤걸로? interface로요~ 1)번 사항 참고
      즉 userDao 쓸려면 connection이 되어야 하죠^^ (의존관계가 서로 있다는 뜻, 즉 둘 다 bean이 등록이 되어야 함.) 외부주입은 setter나 생성자로 보통 하죠~

      DL은 getBean()을 통해서 해당 connectionMaker을 가져올 지라도 usrDao는 빈으로 등록 할 필요가 없다는 뜻이에요 new해서 객체 생성 해도 무관하다는 것이죠

      문의 하신 "검색하는 오브젝트는 UserDao이며 UserDao는 빈으로 등록되어야 한다는 뜻인가요?" 에서 반대로 UserDao가 빈으로 등록되지 않아도 된다는 뜻이라고 생각하시면 됩니다. DL에서요^^

      음..설명을 잘못해서..더 헷깔리실 수 있겠지만..토비 1권을 조금 참조 하시면서 보시면 이해가 가실꺼라 생각합니다^^;

      참고사항으로
      http://acet.pe.kr/220과 http://acet.pe.kr/183 을 보시면 좋을 것 같네요

      열공하세요~~~

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

IoC(Inversion of Control)

OpenSource/Spring 2012.08.07 14:52
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T

출처 : 토비의 스프링3

Spring에서 많이 알려진 용어 이다.

IoC(Inversion of Control) : 제어의 역전

이 개념을 알기 전에 먼저 Spring에서의 Factory에 대해서 알아보자.

팩토리 : 객체의 생성 방법을 결정하고 그렇게 만들어진 오프젝트를 돌려주는 것인데, 이런 일을 하는 오프젝트를 흔히 팩토리라고 부른다.(디자인 패턴의 팩토리와는 다른 것이다.) 

acet : 음..팩토리...오브젝트!!!! 오브젝트의 생성, 리턴등을 하는 오브젝트!!!!!라고 보여진다!

간단히 말하면..  
public class DaoFactory{
    pubilc UserDao userDao(){
        /////////// 팩토리의 메소드는 UserDao 타입의 오브젝트를 어떻게 만들고, 
// 어떻게 준비시킬지 결정 한다.   ConnectionMaker connectionMaker = new DConnectionMaker();    UserDao userDao = new UserDao(connectionMaker);
/////////////////////////////////////////////////////////////   return userDao;    } }


제어의 역전이라는 개념을 알아보자!

간단히
프로그램의 제어 흐름 구조가 뒤바뀌는 것이라고 할 수 있다.

일반적으로는 main() 처럼 프로그램이 시작되는 지점에서 오프젝트를 결정, 생성(new), method 호출, 호출 된 method 안에서 다음에 사용 할 것을 결정 하고 호출 하는 방식이 반복적으로 이루어지고 있다.

제어의 역전이란 이런 제어 흐름의 개념을 거꾸로 뒤집는 것이다.
오브젝트가 자신이 사용 할 오브젝트를 스스로 선택하지 않는다. 어떤 객체를 만들지 생각하지 않는 다는 말.
당연히 생성 하지도 않는다. 

모든 제어 권한이 자신이 아닌 다른 대상에게 위임하기 때문이다.

ex) A Class에서 getAcetInfo()같은 메소드가 구현 되어있다고 하자!! 이 메소드가 언제 어디서 사용 될지는        A Class 자신은 모른다!! 
     다른쪽  B의 method에서  이 구현 된 것을 제어 하는 것이 바로 제어의 역전!!!!!
     대충 이런 개념인 것이다. ^0^good~

이제 Spring에서의 Ioc에 대해서 알아보자!
우선 아래의 그림을 참고하도록 하자!


[IoC와 object Factory의 관계]

acet : factory라는 오브젝트에 대해서 위에서 알아보았다. 객체를 생성, 리턴을 하는 일을 하는 오브젝트!!
IoC는 제어의 역전이라고 해서 생성, 리턴 등을 하는 일을 자기자신이 아닌 다른쪽에서 제어를 하는 것이라고 이해했다. 즉, IoC의 개념에서 보면 생성,리턴을 하는건 factory!! 그런데 그것을 다른쪽에서 제어하는 것이라고 생각하면 좋을 것 같다!(더 헷깔리게 말했나;;)


Spring에서는 Spring이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트를 bean(빈)이라고 부른다.
bean : 자바빈 or EJB에서 말하는 빈과 비슷한 오프젝트 단위의 애플리케이션 컴포넌트를 말한다.

또한, Spring Bean은 컨테이너 생성과 관계설정, 사용 등을 제어해주는 제어의 역전이 적용된 오브젝트를 가리키는 말이다.

Spring에서는 빈의 생성과 관계설정 같은 제어를 담당하는 IoC 오브젝트를 bean factory라고 부른다.

참고사항 :
애플리케이션 컨텍스트 - bean factory보다는 이를 좀 더 확장한 것, IoC 방식을 따라 만들어진 일종의 bean factory라 생각 하면 된다.
스프링 컨테이너라고 부르기도 한다.

애플리케이션 컨텍스트 동작 방식
애플리케이션 컨텍스트는 애플리케이션에서 IoC를 적용해서 관리할 모든 오브젝트에 대한 생성과 관계설정을 담당한다. ApplicationContext 인터페이스를 구현.

Application Context에는 직접 오브젝트를 생성하고, 관계를 맺어주는 코드가 없고, 그런 생성정보와 연관관계 정보를 별도의 설정정보를 통해 얻는다. 
@Configuration이 붙어있으면 애플리케이션 컨텍스트가 활용하는 IoC 설정 정보다.

ex) 

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
...
@Configuration => 애플리케이션 컨텍스트 또는 빈 팩토리가 사용할 설정정보라는 표시
public class DaoFactory{
   @Bean         => 오브젝트 생성을 담당하는 IoC용 메소드라는 표시
   public UserDao(){
       return new UserDao(connectionMaker());
   }
   @Bean
   public   ConnectionMaker connectionMaker(){
       return new DConnectionMaker();
   }
}                                        



★ 스프링 IoC 용어정리
  1) Bean 
   빈 또는 빈 오브젝트는 스프링이 IoC방식으로 관리하는 오브젝트라는 뜻이다.
   ※ 주의할점은 스프링을 사용하는 애플리케이션에서 만들어지는 모든 오브젝트가 다 빈은 아니라는 사실!!
   그중에서 스프링이 직접 그 생성과 제어를 담당하는 오브젝트만을 빈이라고 부른다.

 2) Bean Factory 
 스프링의 IoC를 담당하는 핵심 컨테이너를 가리킨다.
 빈을 등록.생성, 조회하고 돌려주고, 그 외에 부가적인 빈을 관리하는 기능을 담당한다.
 보통은 이 bean factory를 바로 사용하지 않고, 이를 확장한 애플리케이션 컨텍스트를 이용한다.
 BeanFactory라고 붙여쓰면 빈 팩토리가 구현하고 있는 가장 기본적인 인터페이스의 이름이 된다.
이 인터페이스에 getBean()과 같은 메소드가 정의 되어있다.

3) Application Context
Bean Factory를 확장한 IoC컨테이너이다. 빈을 등록하고 관리하는 기본적인 기능은 빈 팩토리와 동일!
여기에 스프링이 제공하는 각종 부가서비스를 추가로 제공한다.

빈 팩토리라고 부를 때는 주로 빈의 생성과 제어의 관점에서 이야기하는 것이고,
애플리케이션 컨텍스트라고 할 때는 스프링이 제공하는 애플리케이션 지원 가능을 모두 포함해서 이야기 하는 것이라고 보면 된다.

스프링에서는 빈 팩토리보다 어플리케이션 컨텍스트라는 용어를 많이 사용한다.
ApplicationContext라고 적으면 애플리케이션 컨텍스트가 구현해야하는 기본 인터페이스를 가리키는 것이기도 하다.
ApplicationContext는 BeanFactory를 상속한다. <--이런 부분은 직접 코딩을 접해봐야 할 것 같다!

4) 설정정보/설정 메타정보    
 스프링의 설정정보란 애플리케이션 컨텍스트 또는 빈 팩토리가 IoC를 적용하기 위해 사용하는 메타정보를 말한다. 영어로 Configuration 이라고 하며, 이는 구성정보 내지는 형상정보라는 의미이다.
실제로 스프링의 설정정보는 컨테이너에 어떤 기능을 셋팅하거나 조정하는 경우에도 사용하지만 그보다도 IoC컨테이너에 의해 관리 되는 애플리케이션 오브젝트를 생성하고 구성 할 때 사용 된다.

5) 컨테이너 or IoC 컨테이너
 IoC방식으로 빈을 관리하는 의미에서 애플리케이션 컨텍스트나 빈 팩토리를 컨테이너 또는 IoC컨테이너라고도 한다.
후자는 주로 빈 팩토리 관점에서 이야기 하는 것이고(IoC컨테이너), 그냥 컨테이너 또는 스프링 컨테이너라고 할 때는 애플리케이션 컨텍스트를 가리키는 것이라고 보면 된다.

acet : 음..대충은 이해가 갔으나..어느정도의 암기가 필요 할 것 같다^0^ good~~
IoC 아시겠죠잉?? ㅋ

마지막으로..스프링으로 개발을 하다가 생각했었던 것이 있었다..처음 자바를 시작했을 때 C언어처럼
객체를 파라미터로 전달하거나 new 연산자를 통해서 객체를 생성하였다.
또한 Spring으로 개발을 하면서 생각했던 것은..new을 다 없애버렸다고 생각하였다.
지금  공부해보니..그 기술이 바로..IoC 인 것이다!!!!!+ㅁ+good~~

- 끝 -




저작자 표시 비영리 변경 금지
신고

acet 박태하가 추천하는 readtrend 추천글!

설정

트랙백

댓글

  • zkimera 2013.02.14 11:48 신고 답글 | 수정/삭제 | ADDR

    좋은 정보 잘 얻어갑니다..ㅎㅎ

    덧글 달았어요..ㅋㅋㅋ

    • Favicon of http://acet.pe.kr BlogIcon String Ace-T 2013.02.18 20:13 신고 수정/삭제

      ㅎㅎㅎㅎㅎ 감사합니다~~
      종종 놀러오세요^-^ 누구신지는 잘모르겠지만여^^;

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

티스토리 툴바