검색결과 리스트
SpringFramework에 해당되는 글 6건
- 2020.08.06 springbatch setting시 오류: Spring Boot plugin requires Gradle 5 (5.6.x only) or Gradle 6 (6.3 or later). The current version is Gradle 4.10.3
- 2018.10.12 Spring Boot + Spring Batch 분석_01
- 2014.05.23 [Ace-T의 Spring강좌] Step 06. Spring @MVC 분석-03
- 2014.02.05 [Ace-T의 Spring강좌] Step 04. Spring @MVC 분석-01
- 2012.12.03 [다섯번째] Spring 사내 스터디
- 2012.11.26 [네번째] Spring 사내 스터디
글
springbatch setting시 오류: Spring Boot plugin requires Gradle 5 (5.6.x only) or Gradle 6 (6.3 or later). The current version is Gradle 4.10.3
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix-dependency-versions
Spring Boot Reference Documentation
This section goes into more detail about how you should use Spring Boot. It covers topics such as build systems, auto-configuration, and how to run your applications. We also cover some Spring Boot best practices. Although there is nothing particularly spe
docs.spring.io
스프링 사용 시 버전에 맞게 사용하자~
디펜던시!!
빌드 툴도 역시나! 버전에 맞게~
Tomcat, jetty 등등도~버전을 체크!
자바 버전도! SpringBoot 2.3.2 Release는 요구된다칸다! 8이상이~
스프링프레임워크는 5.2.8 또는 그 상위가 요구!
그래들은 https://gradle.org/releases/에서 다운 받자!
'OpenSource > Spring Batch' 카테고리의 다른 글
| springboot 2.x 이상 springbatch table문제 해결 방법! (0) | 2020.08.13 |
|---|---|
| springbatch setting시 오류: Spring Boot plugin requires Gradle 5 (5.6.x only) or Gradle 6 (6.3 or later). The current version is Gradle 4.10.3 (0) | 2020.08.06 |
| Spring Boot + Spring Batch 분석_02 (0) | 2018.10.23 |
| Spring Boot + Spring Batch 분석_01 (0) | 2018.10.12 |
| SpringBatch 예제 (0) | 2018.09.12 |
| MyBatisPagingItemReader를 사용할 때 유의점 (0) | 2015.10.02 |
글
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
주저리
spring boot를 사용하여
spring batch를 해보려는데 막상 spring batch를 잘모르면 제대로 못할것 같은 생각이 들었다.
springframework를 spring boot기반으로 해볼때도 마찬가지였다.
구성
- Job과 Step으로 구성.
- Job
- 여러개의 Step으로 구성.
- Step은 ItemReader, ItemProcessor, ItemWriter의 구조이거나
이런 전형적인 구조가 아닐 경우 Tasklet 구조.
분석
2018/09/12 - [OpenSource/Spring Batch] - SpringBatch 예제
에서 처럼 https://spring.io/guides/gs/batch-processing/
공식 사이트를 살펴보도록 하자.
org.springframework.boot:spring-boot-starter-batch 디펜던시는 요녀석!Batch Job을 구성할 때
Spring Batch는 따로 작성할 필요없이 비즈니스 로직에 집중할 수 있도록 많은 유틸리티를 제공한다.
BatchConfiguration! 이부분은 옛날 Spring Batch에서 xml로 구성되던 녀석이다.
@Configuration
@EnableBatchProcessing
public class BatchConfiguration {하나하나씩 보도록 하자. 우선 Factory를 DI 하는 것을 볼수 있다.
@Autowired
public JobBuilderFactory jobBuilderFactory;
@Autowired
public StepBuilderFactory stepBuilderFactory;
// tag::jobstep[]
@Bean
public Job importUserJob(JobCompletionNotificationListener listener, Step step1) {
return jobBuilderFactory.get("importUserJob")
.incrementer(new RunIdIncrementer())
.listener(listener)
.flow(step1)
.end()
.build();
}
@Bean
public Step step1(JdbcBatchItemWriter<Person> writer) {
return stepBuilderFactory.get("step1")
.<Person, Person> chunk(10)
.reader(reader())
.processor(processor())
.writer(writer)
.build();
}
// end::jobstep[]그리고 Step에서 사용되어지는 reader, processor, writer도 함께 구성.
// tag::readerwriterprocessor[]
@Bean
public FlatFileItemReader<Person> reader() {
return new FlatFileItemReaderBuilder<Person>()
.name("personItemReader")
.resource(new ClassPathResource("sample-data.csv"))
.delimited()
.names(new String[]{"firstName", "lastName"})
.fieldSetMapper(new BeanWrapperFieldSetMapper<Person>() {{
setTargetType(Person.class);
}})
.build();
}
@Bean
public PersonItemProcessor processor() {
return new PersonItemProcessor();
}
@Bean
public JdbcBatchItemWriter<Person> writer(DataSource dataSource) {
return new JdbcBatchItemWriterBuilder<Person>()
.itemSqlParameterSourceProvider(new BeanPropertyItemSqlParameterSourceProvider<>())
.sql("INSERT INTO people (first_name, last_name) VALUES (:firstName, :lastName)")
.dataSource(dataSource)
.build();
}
// end::readerwriterprocessor[]구조는 이러하고..이제 조금 더 자세하게 보도록 하자.
More and More
BatchConfiguration.java
- @Configuration : 설정 파일임을 알려준다. @MVC에서 @service @controller와 같다고 보면 된다.
- @EnableBatchProcessing : Batch 관련 유용한 유틸을 제공가능케 한다. 영어 고대로 Enable하겠다는 뜻.
- 위에서 언급한 내용처럼 Factory를 DI 하여 Job과 Step을 구성한다.
- Job은 Step으로 구성하여 만들어지고 Step은 reader, processor, writer를 구성할 수 있다.
- 어노테이션 @Autowired로 DI 해주는 부분.
@Autowired
public JobBuilderFactory jobBuilderFactory;
@Autowired
public StepBuilderFactory stepBuilderFactory;- Job과 Step을 설정 해주는 부분.
@Bean
public Job importUserJob(JobCompletionNotificationListener listener, Step step1) {
return jobBuilderFactory.get("importUserJob")
.incrementer(new RunIdIncrementer())
.listener(listener)
.flow(step1)
.end()
.build();
}
@Bean
public Step step1(JdbcBatchItemWriter<Person> writer) {
return stepBuilderFactory.get("step1")
.<Person, Person> chunk(10)
.reader(reader())
.processor(processor())
.writer(writer)
.build();
} - Job은 아래와 같이 importUserJob이라는 함수명을 가지며, 파라미터로는 listener, step을
- return으로는 JobBuilderFactory를 이용하여 Job을 리턴하는 구조이다.
- jobBuilderFactory.get은 job builder를 생성하고 JobRepository를 초기화 시킨다.
[ Spring Batch 흐름도]
|
- 아래를 좀 더 심화있게 이해하려면 builder pattern을 이해해야한다.
- 하지만 우선적으로 Spring Batch에 대해서 파악하는게 우선이다.
- 이제 돌아와서 incremeter를 보자.
- JobBuilderHelper Class에 속해있는 method이다.
- JobBuilderHelper는 JobBuilder의 부모 클래스이다.
- 포맷은 아래와 같다.
- public B incrementer(JobParametersIncrementer jobParametersIncrementer)
- 파라미터로 JobPrametersIncrementer를 가지는데 이것은 Interface 형태이다.
- 이 Interface를 구현한 녀석이 위에 사용되어진 RunIdIncrementer Class 이다.
- 그리고 incrementer 이녀석이 하는 역할은 JobParametersIncrementer 인터페이스의
역할을 보면 알수 있다. JobParameters를 취득하기 위한 인터페이스이기 때문이다. - JobParameters..! 이녀석을 이해하려면 아래의 그림을 이해해야한다.
- 동시 다발적으로 돌아가는 Job들의 차이는 어떻게 알수가 있나? Job들 간의 구별? 그 해답은 JobParameters에 있다. 그래서 batch job을 시작할 때 이처럼 JobParameters를 취득한다.
더욱 더 자세한 내용은 해당 링크를 참조.
- 그 다음으로 listener.
- JobBuilderHelper Class에 속해 있는 Method이며, format은 아래와 같다.
public B listener(JobExecutionListener listener) - JobExecutionListener도 Interface이며 지금 설명하는 소스에서는
JobCompletionNotificationListener Class에서 extends하고 있다. - JobCompletionNotificationListener.java
package hello; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.batch.core.BatchStatus; import org.springframework.batch.core.JobExecution; import org.springframework.batch.core.listener.JobExecutionListenerSupport; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.jdbc.core.JdbcTemplate; import org.springframework.stereotype.Component; @Component public class JobCompletionNotificationListener extends JobExecutionListenerSupport { private static final Logger log = LoggerFactory.getLogger(JobCompletionNotificationListener.class); private final JdbcTemplate jdbcTemplate; @Autowired public JobCompletionNotificationListener(JdbcTemplate jdbcTemplate) { this.jdbcTemplate = jdbcTemplate; } @Override public void afterJob(JobExecution jobExecution) { if(jobExecution.getStatus() == BatchStatus.COMPLETED) { log.info("!!! JOB FINISHED! Time to verify the results"); jdbcTemplate.query("SELECT first_name, last_name FROM people", (rs, row) -> new Person( rs.getString(1), rs.getString(2)) ).forEach(person -> log.info("Found <" + person + "> in the database.")); } } } - 위의 소스는 job이 BatchStatus.COMPLETED인가에 대해서 listen하고 있다. 그리고나서 JdbcTemplate를 사용한다.
- 다음으로 flow.
- JobBuilder Class에 속해 있는 Method이며, format은 아래와 같다.
public JobFlowBuilder flow(Step step)
딱 봐도 job과 step의 연결 & 수행. return으로는 a SimpleJobBuilder. - 다음으로 end. 즉, builder를 종료.
- 다음으로 build() : 호출하여 최종적으로 a job builder를 리턴.
- 이것은 bulider pattern을 참고.(잘 정리 해놓은 블로그! thx.)
지금까지 Job 관련 내용들을 살펴 보았습니다.
다음 포스팅에서는 비즈니스 로직을 당담하고 있는 Step에 대해서 알아보도록 하겠습니다.
2018/10/23 - [OpenSource/Spring Batch] - Spring Boot + Spring Batch 분석_02
'OpenSource > Spring Batch' 카테고리의 다른 글
| springbatch setting시 오류: Spring Boot plugin requires Gradle 5 (5.6.x only) or Gradle 6 (6.3 or later). The current version is Gradle 4.10.3 (0) | 2020.08.06 |
|---|---|
| Spring Boot + Spring Batch 분석_02 (0) | 2018.10.23 |
| Spring Boot + Spring Batch 분석_01 (0) | 2018.10.12 |
| SpringBatch 예제 (0) | 2018.09.12 |
| MyBatisPagingItemReader를 사용할 때 유의점 (0) | 2015.10.02 |
| Spring Batch 환경 셋팅 (0) | 2012.09.03 |
글
[ 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/03 - [OpenSource/Spring 강좌] - [Ace-T의 Spring강좌] Step 01. Spring 환경 구축 하기(Eclipse+Jdk)
'OpenSource > Spring 강좌' 카테고리의 다른 글
| [Ace-T의 Spring강좌] Step 06. Spring @MVC 분석-03 (0) | 2014.05.23 |
|---|---|
| [Ace-T의 Spring강좌] Step 05. Spring @MVC 분석-02 (0) | 2014.05.05 |
| [Ace-T의 Spring강좌] Step 04. Spring @MVC 분석-01 (0) | 2014.02.05 |
| [Ace-T의 Spring강좌] Step 03. Spring 환경 구축 하기(was) (0) | 2013.12.04 |
| [Ace-T의 Spring강좌] Step 02. Spring 환경 구축 하기(Maven+Spring Project) (5) | 2013.11.05 |
| [Ace-T의 Spring강좌] Step 01. Spring 환경 구축 하기(Eclipse+Jdk) (0) | 2013.11.03 |
글
[ 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/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 org.slf4j.Logger; /** |
하지만 우선~~~!! 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/ 참조 하시면 됩니다.)
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 -
'OpenSource > Spring 강좌' 카테고리의 다른 글
| [Ace-T의 Spring강좌] Step 06. Spring @MVC 분석-03 (0) | 2014.05.23 |
|---|---|
| [Ace-T의 Spring강좌] Step 05. Spring @MVC 분석-02 (0) | 2014.05.05 |
| [Ace-T의 Spring강좌] Step 04. Spring @MVC 분석-01 (0) | 2014.02.05 |
| [Ace-T의 Spring강좌] Step 03. Spring 환경 구축 하기(was) (0) | 2013.12.04 |
| [Ace-T의 Spring강좌] Step 02. Spring 환경 구축 하기(Maven+Spring Project) (5) | 2013.11.05 |
| [Ace-T의 Spring강좌] Step 01. Spring 환경 구축 하기(Eclipse+Jdk) (0) | 2013.11.03 |
글
[ 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
'Study > Study group' 카테고리의 다른 글
| [2번째] KSUG+자바카페 2013년 상반기 스터디 (0) | 2013.03.23 |
|---|---|
| KSUG+자바카페 2013년 상반기 스터디 (0) | 2013.03.16 |
| [다섯번째] Spring 사내 스터디 (0) | 2012.12.03 |
| [네번째] Spring 사내 스터디 (0) | 2012.11.26 |
| 자바카페 KSUG 스프링 스터디 (0) | 2012.11.24 |
| [세번째] Spring 사내 스터디 (0) | 2012.11.12 |
글
[ 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 사내 스터디
토비 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
구분 가능.
'Study > Study group' 카테고리의 다른 글
| KSUG+자바카페 2013년 상반기 스터디 (0) | 2013.03.16 |
|---|---|
| [다섯번째] Spring 사내 스터디 (0) | 2012.12.03 |
| [네번째] Spring 사내 스터디 (0) | 2012.11.26 |
| 자바카페 KSUG 스프링 스터디 (0) | 2012.11.24 |
| [세번째] Spring 사내 스터디 (0) | 2012.11.12 |
| [KSUG+Java cafe] 스프링 스터디 (0) | 2012.11.10 |
