스프링 사이트(https://spring.io/)가 리모델링을 거쳤다.

전체적으로 깔끔해지고 카테고리가 정리되었다.

그와 함께 스프링 부트의 위상이 크게 격상되었다는 것도 보인다.

스프링 부트로 만들고

스프링 클라우드로 결합시키고

스프링 클라우드 데이터 플로우로 뭐든지 연결한다!? (아직 스프링 클라우드 데이터 플로우 쪽에는 가보지도 못했는데...)

말그대로 스프링 플랫폼을 위한 기반으로서 확고한 자리를 잡았다. 쉽게 개발하고 배포 및 운영이 용이하기 때문에 앞으로도 꾸준하게 사용자가 늘어날 것이다.

그런 의미에서!! 다음달 중에 나올 제 책을 꼭~ 봐주세요. ㅎㅎ


  1. 2018.06.24 10:47

    비밀댓글입니다

    • 개인적으로 스프링을 공부해야하는데 스프링 부트로 시작하게 되면 배우는 게 많이 없을 겁니다.

      애플리케이션에 필요한 대부분의 기능을 스프링 부트에서 관례(Convention)으로 구성한 자동 구성으로 처리가 되어 있으니까요.

      스프링 부트 소스를 보시면 어떻게 구성하는지를 이해하는데는 도움이 될 겁니다.

      이 책은 스프링 부트를 사용하면서 막히는 부분들에 대한 참고서 정도로 이해해주시면 되겠습니다.

  2. 질문 2018.07.11 16:30 신고

    Boot spring boot 책을 기다리고 있는데, 이 책은 어떤 버전을 기준으로 집필된 책인가요?

스프링 부트 2.0 정식 출시

스프링 부트 2.0 새로운 점:

  • A Java 8 baseline, and Java 9 support.
  • Reactive web programming support with Spring WebFlux/WebFlux.fn.
  • Auto-configuration and starter POMs for reactive Spring Data Cassandra, MongoDB, Couchbase and Redis.
  • Support for embedded Netty.
  • HTTP/2 for Tomcat, Undertow and Jetty.
  • A brand new actuator architecture, with support for Spring MVC, WebFlux and Jersey.
  • Micrometer based metrics with exporters for Atlas, Datadog, Ganglia, Graphite, Influx, JMX, New Relic, Prometheus, SignalFx, StatsD and Wavefront.
  • Quartz scheduler support.
  • Greatly simplified security auto-configuration.

정리

기다리고 기다리던 스프링 부트 2.0이 정식으로 출시되었다.

스프링 부트 2.0 출시에 맞춰서 쓰고 있는 책은 내일 교정본을 받고 최대한 빨리 출간할 예정이다.

스프링 부트 2.0에서 크게 달라진 점은 스프링 프레임워크 5를 기반으로 하여 리액티브 지원이 가장 큰 부분이라고 생각된다.

아직까지는 리액티브 웹 프로그래밍을 적극적으로 활용한 경험은 없는 상태라서 살펴봐야할 부분이 많다.

살펴볼 수 있다.

관심가는 변화 중 하나는 JDBC 라이브러리가 Tomcat JDBC에서 HikariCP 로 변경되었다.

기존에는 Tomcat JDBC를 제외(exclude)하고 HikariCP 의존성을 추가해야했지만 지금은 굳이 그럴 필요가 없어졌다.

그리고 운영과 관련된 액츄에이터(Actuator)에서 DropWizard에 맞춰 지원하던 형식이 Micrometer에서 쉽게 사용할 수 있도록 개편되었다. 더불어서 액츄에이터 기본경로에 /actuator가 접두사로 붙게 되었다.

그레이들 관련한 플러그인도 조금 더 개선이 될 것으로 보인다.

참고


스프링 시큐리티와 연계하여 로그인에 실패했을 경우 로그인화면으로 리다이렉트 시키면서 이메일을 다시 입력폼에 유지하려고 여러가지 시도를 해봤다.

스프링 시큐리티에서 로그인 실패를 담당하는 인터페이스는 AuthenticationFailureHandler 이다.

public interface AuthenticationFailureHandler {
 
/**
 * Called when an authentication attempt fails.
 * @param request the request during which the authentication attempt occurred.
 * @param response the response.
 * @param exception the exception which was thrown to reject the authentication
 * request.
 */
void onAuthenticationFailure(HttpServletRequest request,
HttpServletResponse response, AuthenticationException exception)
throws IOExceptionServletException;
}

위의 형태를 가지는 간단한 인터페이스로, 스프링 시큐리티 설정에서 formLogin() 에 설정하면 로그인이 실패했을 떄 호출되며 이에 대한 처리를 수행한다.

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .anyRequest().authenticated()
        // form 로그인 
        .and()
        .formLogin()
        .loginPage("/login").permitAll()
        .usernameParameter(USERNAME_PARAMETER)
        .passwordParameter(PASSWORD_PARAMETER)
        .successHandler(authenticationSuccessHandler()) (1)
        .failureHandler(authenticationFailureHandler()) (2)
}
 
// 생략 
@Bean
AuthenticationSuccessHandler authenticationSuccessHandler() {
    return new HoneymonUserAuthenticationSuccessHandler();
}
 
@Bean
AuthenticationFailureHandler authenticationFailureHandler() {
    return new HoneymonUserAuthenticationFailureHandler();
}
로그인 성공시 후속처리
로그인 실패시 후속처리

그리고 HoneymonUserAuthenticationFailureHandler가 호출되면 /login?error={message}&email={email}의 형식으로 리다이렉트되도록 해뒀다. 그런데 암만 로그인 실패가 나도 /login?error= 로 리다이렉트 되지를 않는 것이다. 이 문제 떄문에 한참 씨름을 했다.

public class HoneymonUserAuthenticationFailureHandler implements AuthenticationFailureHandler {
 
    @Override
    public void onAuthenticationFailure(HttpServletRequest request, HttpServletResponse response, AuthenticationException exception) throws IOExceptionServletException {
        if(exception instanceof BadCredentialsException) {
            exception = new BadCredentialsException("security.exception.bad_credentials");
        }
        response.sendRedirect("/login?error=" + exception.getMessage() + "&email=" + request.getParameter(USERNAME_PARAMETER));
    }
}

옆에 누군가가 봐줬으면 참 좋았을텐데…​

그러다가 정말 우연찮게

'아, 내가 LoginWeb' 클래스를 지우고 ViewController 로 처리하도록 했지?

하는 생각이 미쳤다. 리다이렉트가 되지 않고 있는 url에 대해서는 다음과 같이 설정되어 있었다.

@Configuration
public class WebConfig  extends WebMvcConfigurerAdapter {
  @Override
    public void addViewControllers(ViewControllerRegistry registry) {
        registry.addViewController("/login").setViewName("front/login");  // 로그인 
        registry.addViewController("/signup").setViewName("front/signup");  // 회원가입 
    }
}

이 간단한 설정이 나를 괴롭혔던 주 원인이었다.

ViewController 에서 /login 요청에 대한 처리를 수행하기는 하지만 뒤에 전달되는 파라미터들을 모두 소거시킨다는 것을 이해하지 못한 것이다.

어떤 장애든지 기본적인 접근은 그 장애에 영향을 주는 설정부터 살펴보도록 하자. ㅡ_-);; 내가 허비한 시간 우짤꺼야!!

This is a shortcut for defining a ParameterizableViewController that immediately forwards to a view when invoked. Use it in static cases when there is no Java controller logic to execute before the view generates the response.



  1. 2017.06.13 11:54

    비밀댓글입니다

    • ViewController 처리방법 대신,
      Controller 클래스를 정의해서 사용하시면 됩니다.

      @Controller
      @RequestMapping("/{url}";)
      public class HoneymonController {

      // 코드 생략
      }

현재 스프링부트 1.3.1 버전으로 해서

spring-webmvc-4.2.4.RELEASE

버전을 사용중인데,

윈도우와 리눅스에서 결과가 미묘하게 다르다?

윈도우에서는 컨트롤러에서 발생한 NullPointException을 @ControllerAdvice 컴포넌트서 잡질 못하고 그대로 NullPointException을 뱉었고

리눅스에서는 컨트롤러에서 발생한 NullPointException을 @ControllerAdvice 컴포넌트에서 잡아서 변환처리를 해줬다.


Spring application development and analysis process


최근 스프링개발환경은 많은 변화가 있었다. 고전적인 XML 설정방식외에도 JavaConfig 방식이 가능해졌고, 기존에 설정의 복잡함을 줄이기 위한 관례적인 설정을 자동으로 제공하는 자동설정Auto-configuration을 제공하는 스프링부트(http://projects.spring.io/spring-boot/) 프로젝트를 기반으로 한 애플리케이션 개발환경이 제공되고 있다.


1. 스프링애플리케이션 개발순서

  1. 스프링애플리케이션 기능설계

  2. 스프링 프로젝트 빌드

  3. web.xml 설정

    1. servlet 3.0+ 이상을 적용하는 경우에는 ServletInitializer를 통해서 web.xml 설정 대체가능

  4. 스프링 애플리케이션 컨텍스트ApplicationContext 설정

    1. application-context.xml(DAO, 서비스 영역)

      1. datasource 설정

      2. AOP 설정

    2. web-application-context.xml(웹 영영)

    3. security-context.xml(웹접근 인증 설정)

      1. URL과 사용자 권한을 기준으로 접근제어

  5. 애플리케이션 컨텍스트 정상설정 테스트

  6. MyBatis 를 사용하느냐, 하이버네이트등의 ORM 을 사용하느냐에 따라 DB 사용방식 달라짐

    1. MyBatis 인 경우에는 Database 에 스키마와 테이블들이 생성되어 있어야 함

      1. Mapper 클래스 및 SQL 을 설정해줘야 함

      2. iBatis 말고 MyBatis 사용을 권장: iBatis는 개발지원이 끝난지 꽤 되었음

      3. MyBatis와 관련된 부분은 MyBatis를 참고

    2. ORM인 경우에는 개발단계에서 ddl-auto 의 설정을 통해서 테이블 및 컬럼의 자동생성처리가 가능

      1. Spring Data JPA를 사용할 경우 기본적인 CRUD 처리를 JPARepository를 통해서 처리가 가능함

      2. 이와 관련된 자세한 내용은 자바 ORM 표준 JPA 프로그래밍 을 살펴보기

  7. 이후 애플리케이션의 패키지를 구성하고 기능별로 계층을 나눠 개발

io.honeymon.spring
  configuration
    - WebConfiguration.java
  domain
    - Member.java
    - Project.java
  repository
    - MemberRepository.java
    - ProjectRepository.java
  service
    - MemberService.java
    - DefaultMemberService.java
    - ProjectService.java
    - DefaultMProjectService.java
  web
    - MemberController.java
    - ProjectController.java
  common
    - FileUtils.java
    - DateUtils.java

위와 같은 형태로 기능별로 계층을 나눠 개발하기도 하고

io.honeymon.spring
  configuration
    - WebConfiguration.java
  member
    - Member.java
    - MemberRepository.java
    - MemberService.java
    - DefaultMemberService.java
    - MemberController.java
  project
    - Project.java
    - ProjectRepository.java
    - ProjectService.java
    - DefaultProjectService.java
    - ProjectController.java

와 같은 기능별 패키지로 나눠 개발하는 방식도 있습니다. 저도 최근에 이 방식으로 변환을 시도하고 있다.

위와 같은 형태로 개발을 진행합니다.

  1. 애플리케이션 개발에 있어서 MyBatis 보다는 JPA 사용을 선호함. MyBatis 는 4년전 이후로 사용해본 경험없음

  2. ORM을 기반으로 개발하면 엔티티 객체를 기반으로 해서 DB와의 매핑처리도 쉽고 기능구현도 쉬움.


스프링부트를 기반으로 개발하게 될 경우, 스프링과 관련된 설정의 부담감이 줄고 개발에 필요한 라이브러리들을 `Starter-POM`s 를 통해서 쉽게 처리가 가능하기 때문에 스프링 프레임워크에 대한 이해가 어느정도 있는 개발자에게는 스프링부트 사용을 권함

1.1. 화면개발

  1. 기본설정이 완료된 후에는 개발하는 화면에 따라 기능 구현 시작

  2. JSP 페이지 등의 템플릿 파일 작성

  3. Controller ModelAndView 에 템플릿 페이지 등록

    1. ajax 를 활용할 경우 화면처리를 담당할 컨트롤러와 데이터를 JSON으로 처리해줄 컨트롤러를 분리하면 좋음

    2. Spring 4.0 이후 @RestController 애노테이션이 생겨서 요청한 컨텐트타입으로 반환해주는 컨트롤러를 만들 수 있음

  4. 화면에 필요한 데이터를 담을 데이터들을 ModelAndView 혹은 템플릿엔진을 사용하는 경우에는 Model에 담아주면 ViewResolver에 의해서 처리됨

  5. 화면에 필요한 데이터에 따라서 Controller에서 Model에 담아주는 데이터가 달라지고 이는Service의 구현이 필요해짐

    1. 화면데이터에 따라 데이터, 서비스 가 달라짐

2. 스프링 애플리케이션 분석

2.1. 고전적인 XML 설정을 기반으로 한 경우

  1. web.xml 찾아서 애플리케이션 필터 설정들을 확인

  2. application-context.xml 혹은 *-context.xml 파일 분석

    1. application-context.xml: 파일은 보통 src/main/resource/META-INF에 위치

    2. web-application-context.xml: 파일은 보통 WEB-INF 에 위치

    3. 프로젝트를 설정한 사람에 따라 파일명이나 위치는 다를 수 있으므로 파일찾기를 통해서 찾아보기 바람

  3. DB 설정 확인

  4. 애플리케이션 패키지 구성 확인

  5. 애플리케이션을 구동하면서 찍히는 로그를 통해서 동작순서 확인

  6. 관련한 설정 확인

2.2. JavaConfig 인 경우

  1. @Configuration 애노테이션을 사용한 클래스 탐색

  2. 나머지 항목들은 고전적인 XML 설정을 기반으로 한 경우 와 동일

2.3. STS를 이용한 경우


STS: Spring Tool Suite http://spring.io/tools/sts
  1. spring explorer view 를 활용해서 각 설정빈을 확인 가능함

3. 참고자료


+ Recent posts