CommandLineRunner

CommandLineRunner는 구동 시점에 실행할 코드가 있을 때 사용합니다. @Component가 붙은 클래스에 인터페이스를 생성하거나 @SpringBootApplication이 붙은 클래스에 사용해도 됩니다.

 

@SpringBootApplication
public class PianoScoreApplication implements CommandLineRunner {

	public static void main(String[] args) throws Exception {
		SpringApplication.run(PianoScoreApplication.class, args);
	}

	@Override
	public void run(String... args) throws Exception {
		// TODO Auto-generated method stub
		System.out.println("CommandLineRunner-Test");
	}
}

 

@Component
public class Initializationdb implements CommandLineRunner {

	@Override
	public void run(String... args) throws Exception {
		// TODO Auto-generated method stub
		System.out.println("Initialization");

	}
}

ApplicationRunner

ApplicationRunner 인터페이스도 CommandLineRunner와 마찬가지로 구동 시점에 run()을 호출해 준다.

해당 클래스에 @Componet를 붙여줘야 합니다.

 

@Override
public void run(ApplicationArguments args) throws Exception {
	// TODO Auto-generated method stub
	System.out.println("Initialization");	
}

 

ApplicationReadyEvent

@EventLister를 사용하여 스프링 프레임워크가 구동되어 서비스 요청을 받을 준비가 되었을 때 ApplicationReadEvent 발생시켜 초기화를 해줍니다.

@EventListener(ApplicationReadyEvent.class)
public void init() {
	System.out.println("============ApplicationReadyEvent============");
}

 

CommandLineRunner와 ApplicationRunner

만일 순서를 지정하지 않을 경우 ApplicationRunner가 CommandLineRunner 보다 먼저 실행됩니다.

@Order 어노테이션을 사용하여 순서를 정해준다면 정해진 순서대로 실행됩니다.

 

// SpringApplication 클래스에 있는 함수입니다. 직접만든거 아님...
public class SpringApplication{

	private void callRunners(ApplicationContext context, ApplicationArguments args) {
		List<Object> runners = new ArrayList<>();
        	// ApplicationRunner 
        	runners.addAll(context.getBeansOfType(ApplicationRunner.class).values());
        	//CommandLineRunner
		runners.addAll(context.getBeansOfType(CommandLineRunner.class).values());
        	// order 어노테이션이 있는 경우.
		AnnotationAwareOrderComparator.sort(runners);
		for (Object runner : new LinkedHashSet<>(runners)) {
			if (runner instanceof ApplicationRunner) {
				callRunner((ApplicationRunner) runner, args);
			}
			if (runner instanceof CommandLineRunner) {
				callRunner((CommandLineRunner) runner, args);
			}
		}
	}
}

 

 

전체적인 실행 순서

 

 

참고

https://madplay.github.io/post/run-code-on-application-startup-in-springboot

https://spring.io/guides/topicals/spring-security-architecture

 

Spring Security Architecture

this topical is designed to be read and comprehended in under an hour, it provides broad coverage of a topic that is possibly nuanced or requires deeper understanding than you would get from a getting started guide

spring.io

주의 사항

  1. 틀렸을 확률이 매우 큽니다.
  2. 영어를 못해서 해석이 잘못되어 있을 수도 있습니다.
  3. 뭔가 멋있어 보이려고 위에 문서에서 발취해 왔습니다.
  4. 간략히 정리한 글입니다.
  5. 계속해서 수정할 것입니다. :)

Authentication and Access Control

 

Authentication - 권한

인증을 제공하기 위한 주요 인터페이스 전략은 AuthenticiationManager입니다.

 

public interface AuthenticationManager {

  Authentication authenticate(Authentication authentication)
    throws AuthenticationException;
}

 

AuthenticationManager의 주요 기능 3가지 :

  • AuthenticationManager은 유효한 계정을 입력할 경우 인증된 계정을 리턴한다. (DB에 있는 데이터?)
  • 유효하지 않는 계정을 입력할 경우 AuthenticationException을 반환한다. 
  • 정보가 없다면 null을 반환한다.

 - 짧은 정리

DB안에 입력받은 계정의 정보가 있다면 그 어떤 

 

AuthenticationException 특징

  • 401을 반환
  • AuthenticationException은 런타임 오류

 

Customizing Authentication Managers

스프링 시큐리티는 어플리케이션에 authentication manager의 기능을 빠르게 만들 수 있는 환경 설정을 제공해줍니다.

 

 

@Configuration
@EnableWebSecurity // 스프링 시큐리티 필더가 스프링 필터체인에 등록이 됩니다.
public class SecurityConfig extends WebSecurityConfigurerAdapter {

	// 해당 메서드의 리턴되는 오브젝트를 IoC로 등록해준다.
	@Bean
	public BCryptPasswordEncoder encodePassWd() {
		return new BCryptPasswordEncoder();
	}
	
	@Override
	protected void configure(HttpSecurity http) throws Exception {
		http.csrf().disable();
		http.authorizeRequests()
		.antMatchers("/user/**").authenticated()
		.antMatchers("/manager/**").access("hasRole('ROEL_ADMIN') or hasRole('ROLE_MANAGER')")
		.antMatchers("/admin/**").access("hasRole('ROLE_ADMIN')")
		.anyRequest().permitAll()
		.and().formLogin().loginPage("/loginForm")
		.loginProcessingUrl("/login")
		.loginProcessingUrl("/")
		;
	}
	// 로그인을 하지 않으면 /user로 들어가는 경로는 403페이지 오류가 뜸 (권한이 없다는 뜻)
}

 

Authorization - 허가

권한이 부여된 사용자만이 특정 URL을 접속할 수 있도록 도와줍니다. 로그인이 성공적으로 이루어 진다면 AccessDecisionManager가 허가의 여부를 판단합니다. 보통은 정의하지 않고 디폴트로 사용합니다.

 

 

특별한 명명 규칙이 있습니다 

1. ROLE_ADMIN or ROLE_ADMIN처럼 접두사에 ROLE_ 처럼 사용할 수 있습니다.

2. SpEL 표현식도 사용 가능합니다. 예를들어 isFullyAuthenticated() 나 hasRole('user')와 같이 사용할 수 있습니다.

access("hasRole('ROEL_ADMIN') or hasRole('ROLE_MANAGER')")
access("hasRole('ROLE_ADMIN')")

 

ProceedingJoinPoint

: 중요하다고 생각되는 메서드들의 설명

메서드 설명
proceed() AOP가 적용된 메서드의 내용이 실행되야 할 때
getTarget() AOP 대상 객체
getArgs() AOP가 적용된 메서드의 파라미터
getSourceLocation() ( ... )
getStaticPart() 요청된 execution 문

 

-ex

logger.info("getSignature = {}", joinpoint.getSignature());
logger.info("getTarget = {}", joinpoint.getTarget());
logger.info("getArgs = {}", joinpoint.getArgs());
logger.info("getSourceLocation = {}", joinpoint.getSourceLocation());
logger.info("getStaticPart = {}", joinpoint.getStaticPart());
getSignature = String com.piano.score.mvc.controller.TestController.test(int)
getTarget = com.piano.score.mvc.controller.TestController@6fbfef40
getArgs = 4
getSourceLocation = org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint$SourceLocationImpl@899f2b6
getStaticPart = execution(String com.piano.score.mvc.controller.TestController.test(int))

 

 

jointPoint.proceed()

: AOP가 적용된 메서드의 내용이 실행되야 할때 사용 리턴 값은 AOP가 적용된 메서드의 반환된 값

 

 - proceed가 적용되지 않는 코드

- 결과

-  proceed가 적용된 코드

- 결과

 

jointPoint.getSignature()

: AOP가 적용된 메서드를 보여준다.

Junit 이란? 


Junit 테스트는 프로젝트를 구동하지 않고 코드 테스트를 지원해주는 라이브러리이다.

 

pom.xml에 의존 설정

더보기

<!-- https://mvnrepository.com/artifact/junit/junit -->
<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.13.2</version>
    <scope>test</scope>
</dependency>

 

Junit 어노테이션 정리


@Test

테스트를 수행하는 메서드를 지정한다. 각각의 테스트가 서로 영향을 주지 않고 독립적으로 실행한다.

 

@Ignore

테스트를 실행하지 않도록 해주는 어노테이션이다. 테스트를 실행할 때 포함하지 않는다.

 

@Before / @After

테스트 메소다가 실행되기 전, 후로 항상 실행되는 메소드를 지정한다. 공통적으로 실행되어야 하는 메소드에 달아주면 된다.

 

@BeforeClass / @AfterClass

각각의 메소드가 아닌 해당 클래스에서 딱 한번 수행되는 메서드이다.

 

 

@RunWith(SpringJUnit4ClassRunner.class)

ApplicationContext를 만들고 관리하는 작업을 할 수 있도록 JUnit의 기능을 확장해준다.

 

 

@ContextConfigureation(location="classpath:xml파일위치")

스프링 빈 설정 파일의 위치를 지정할 수 있다. 별도의 컨테이너를 추가하지 않고 빈을 등록해둔 xml 파일을 지정해 컨테이너에 등록해준다.

 

@Autowired

자동으로 의존성 주입을 해준다.

 

import org.junit.After;
import org.junit.Before;
import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;

@SpringBootTest
class PianoScoreApplicationTests {

	@Before
	void before() {
		System.out.println("before");
	}

	@Test
	void contextLoads() {
		System.out.println("Test");
	}

	@After
	void after() {
		System.out.println("after");
	}

}

AOP는 Ioc/DI, 서비스 추상화와 더불어 스프링의 3대 기반기술 중 하나입니다. AOP를 바르게 이용하려면 OOP를 대체하려고 하는 것처럼 보이는 AOP의 등장 배경과 도입한 이유를 토비 스프링 책을 토대로 정리해볼까 합니다. 

 

AOP는 무엇인가?


AOP(Aspect Oriented Programming)는 횡단 관심사의 분리를 허용함으로써 모듈성을 증가시키는 것이 목적인 프로그래밍 패러다임입니다. 프로그램 코드에서 핵심적인 기능을 수행하는 부분과 부가 기능을 나누는 것을 목적으로 합니다.

 

예를 들어 로직에  로그를 추적하는 코드가 들어가야 한다면 각 핵심 기능 객체마다 로그 추적 코드가 섞여 들어가게 됩니다. 또한 부가 기능이 구조적으로 단순한 호출이 아니라 try~catch~finally 같은 구조가 필요하다면 더욱 복잡해지며, 만일 부가 기능을 수정해야하는 일이 발생한다면 부가 기능을 가진 컨트롤러 , 서비스 ,리포지토리에 있는 모든 로직을 일일이 수정해야 합니다.

 

부가 기능 문제

  • 부가 기능을 적용할 때 아주 많은 반복이 필요하다.
  • 부가 기능이 여러 곳에 퍼져서 중복 코드를 만들어낸다.
  • 부가 기능을 변경할 때 중복 때문에 많은 수정이 필요하다.
  • 부가 기능의 적용 대상을 변경할 때 많은 수정이 필요하다.

소프트웨어 개발에서 변경 지점은 하나가 될 수 있도록 잘 모듈화 되어야 한다. 그런데 부가 기능처럼 특정 로직을 애플리케이션 전반에 적용하는 문제는 일반적인 OOP 방식으로는 해결이 어렵다.

Ex) 트랜잭션 분리

//부가 기능
public void upgradeLevels() throws Exception {
		
       TransactionStatus status 
       		= this.transactionManager.getTransaction(new DefaultTransactionDefinition());
		
        try{
            userUpgrade();
            this.transactionManager.commit(status);
        } catch(Exception e){
        	this.trasactionManager.rollback(status);
            throw e;
        }
}

// 핵심 기능
public void userUpgrade() {
	List<User> users = userDao.getAll();
	for (User user : users) {
		if (canUpgradeLevel(user)) {
			upgradeLevel(user);
		}
	}
}

 

 

AOP 소개 - 애스펙터


핵심 기능과 부가 기능을 분리

부가 기능을 핵심 기능에서 분리하고 한 곳에서 관리하도록 만들고, 해당 부가 기능을 어디에 적용할지 선택하는 기능을 합해서 하나의 모듈로 만든 것이 애스펙트(aspect)입니다.

 

이렇게 애스펙트를 사용한 프로그래밍 방식을 관점 지향 프로그래밍 AOP라고 합니다.

 

※ AOP는 OOP를 대체하기 위한 것이 아니라 횡단 관심사를 깔끔하게 처리하기 어려운 OOP의 부족한 부분을 보조하는 목적으로 개발된 것입니다.

 

AspectJ 프레임워크

AOP의 대표적인 구현으로는 AspectJ 프레임워크가 있으며, 스프링도 AOP를 지원하지만 AspectJ를 문법을 사용하고, 기능의 일부만 제공합니다. 

 

 

 

AOP 적용 방식


AOP를 사용할 때 부가기능을 추가하는 방식은 컴파일 시점, 클래스 로딩 시점 런타임 시점이 있습니다.

 

컴파일 시점

 .java 소스 코드를 컴파일러를 사용해서 .class를 만드는 시점에 부가 기능 로직을 추가할 수 있습니다.

이때는 AspectJ가 제공하는 특별한 컴파일러를 사용해야 합니다. 컴파일 된 .class를 티 컴파일 해보면 애스펙트 관련 호출 코드가 들어갑니다. 참고로 원본 로직에 부가 기능 로직이 추가되는 것을 워빙(이라고 합니다.

 

- 단점 : 컴파일 시점에 부가 기능을 적용하려면 특별한 컴파일러도 필요하고 복잡합니다.

 

 

클래스 로딩 시점

 자바를 실행하면 자바 언어는 .class 파일을 JVM 내부의 클래스 로더에 보관합니다. 이때 중간에서 .class 파일을 조작한 다음 JVM에 올릴 수 있니다. 자바 언어는 .class 를 JVM에 저장하기 전에 조작할 수 있는 기능을 제공합니다.

 

- 단점 : 로드 타임 워빙은 자바를 실행할 때 특별한 옵션( java -javaagent)을 통해 클래스 로더 조작기를 지정해야 하는데 이 부분이 번거롭고 운영하기 어렵다.

 

 

런타임 시점

 런타임 시점은 컴파일도 다 끝나고, 클래스 로더에 클래스도 다 올라가서 이미 자바가 실행되고 난 다음을 말합니다. 자바의 메인 메서드가 이미 실행된 다음이고, 자바 언어가 제공하는 범위 안에서 부가 기능을 적용해야 합니다. 스프링과 같은 컨테이너의 도움을 받고 프록시와 DI, 빈 포스트 프로세서 같은 개념들의 도움을 받아야 합니다.  

 

 

차이점

  • 컴파일 시점: 실제 대상 코드에 애스팩트를 통한 부가 기능 호출 코드가 포함된다. AspectJ를 직접 사용해야 한다
  • 클래스 로딩 시점: 실제 대상 코드에 애스팩트를 통한 부가 기능 호출 코드가 포함된다. AspectJ를 직접 사용해야 한다
  • 런타임 시점: 실제 대상 코드는 그대로 유지된다. 대신에 프록시를 통해 부가 기능이 적용된다. 따라서 항상 프록시를 통해야 부가 기능을 사용할 수 있다. 스프링 AOP는 이 방식을 사용한다

 

AOP 용어 정리

 

조인 포인트(Join point)

  • 어드바이스가 적용될 수 있는 위치, 메소드 실행, 생성자 호출, 필드 값 접근, static 메서드 접근 같은 프로그램 실행 중 지점
  • 조인 포인트는 추상적인 개념이다. AOP를 적용할 수 있는 모든 지점이라 생각하면 된다.
  • 스프링 AOP는 프록시 방식을 사용하므로 조인 포인트는 항상 메소드 실행 지점으로 제한된다.

포인트컷(Pointcut)

  • 조인 포인트 중에서 어드바이스가 적용될 위치를 선별하는 기능
  • 주로 AspectJ 표현식을 사용해서 지정
  • 프록시를 사용하는 스프링 AOP는 메서드 실행 지점만 포인트컷으로 선별 가능

타켓(Target)

  • 어드바이스를 받는 객체, 포인트컷으로 결정

어드바이스(Advice)

  • 부가 기능
  • 특정 조인 포인트에서 Aspect에 의해 취해지는 조치
  • Around(주변), Before(전), After(후)와 같은 다양한 종류의 어드바이스가 있음

애스펙트(Aspect)

  • 어드바이스 + 포인트컷을 모듈화 한 것
  • @Aspect 를 생각하면 됨
  • 여러 어드바이스와 포인트 컷이 함께 존재

어드바이저(Advisor)

  • 하나의 어드바이스와 하나의 포인트 컷으로 구성
  • 스프링 AOP에서만 사용되는 특별한 용어

 

1. 데이터 바인딩

 


@Requestparm , @PathVariable, @ModelAttribute, @SessionAttributes 등 각종 어노테이션을 이용하여 사용자로부터 컨트롤러에 데이터를 전달되는 값을 서버가 원하는 데이터 형식에 맞게 변환해주는 작업입니다.

 

 

 

2. 데이터 바인딩 종류


스프링은 바인딩 과정에서 필요한 변환 작업을 위해 기본적으로 두가지 종류의 API를 제공합니다.

 

 

PropertyEditor

 

- 디폴트 프로퍼티 에디터

 

@RequestMapping("/hello")
public void hello(@RequestParam Charset charset, Model model){
	//URL이 /hello?charset=UTF-8이라면, 다음 컨트롤러 메소드의 charset 파라미터는 UTF-8으로 설정 된다.
}

 

@PostMapping("/login") //스프링이 자동으로 RequestLoginEntity를 바인딩 해준다.
public ModelAndView login(@ModelAttribute RequestLoginEntity RequestLoginEntity) {
	ModelAndView andView = new ModelAndView("/home");
	return andView;
}
public class RequestLoginEntity {

	private String email;
	private String password;

	public RequestLoginEntity(String email, String password) {
		super();
		this.email = email;
		this.password = password;
	}

	public RequestLoginEntity() {
		// TODO Auto-generated constructor stub
	}

	// --- 
    
   	// getter  , setter
    
   	// ----

}
  • 바인딩 과정에서는 변환할 파라미터 또는 모델 프로퍼티의 타입에 맞는 프로퍼티 에티터가 자동으로 선정돼서 사용됩니다.
  • 디폴트 바인딩을 위해서는 setter, getter가 있어야 합니다.

 

 

- 커스텀 프로퍼티 에디터

 

애플리케이션에서 직접 정의한 타입으로 직접 바인딩을 하고 싶다면, 프로퍼티 에디터를 직접 작성하면 됩니다.

 

예제

public class LoginPropertyEditor extends PropertyEditorSupport {

	@Override
	public String getAsText() {
		// TODO Auto-generated method stub
		return super.getAsText();
	}
	
	@Override
	public void setAsText(String text) throws IllegalArgumentException {
		// TODO Auto-generated method stub
		super.setAsText(text);
	}
}

 

 

 

@InitBinder 

@Controller 메소드를 호출해줄 책임이 있는 AnnotationMethodHandlerAdapter는 @RequestParam이나 @ModelAttribute, @PathVariable 등처럼 HTTP 요청을 파라미터 변수에 바인딩해주는 작업이 필요한 어노테이션을 만나면 먼저 WebDataBinder를 만든다.

 

WebDataBinder는 여러가지 기능을 제공하는데, 그중에 HTTP 요청으로부터 가져온 문자열을 파라미터 타입의 오브젝트로 변환하는 기능도 포함되어 있다. 물론 이 변환 작업은 프로퍼티 에디터를 이용한다.

개발자가 만든 커스텀 프러퍼티 에디터를 @RequestParam과 같은 메소드 파라미터 바인딩에 적용하려면 WebDataBinder에 프로퍼티 에디터를 직접 등록해줘야 한다.

 

@InitBinder
	public void init(WebDataBinder binder) {
		binder.registerCustomEditor(Event.class, new EventPropertyEditor());
	}

	@GetMapping(value = "/bindingtest")
	public void event(@ModelAttribute Event event) {
		System.out.println("id "+ event.getId() + " , name :" +event.getName());
	}
public class EventPropertyEditor extends PropertyEditorSupport {

	@Override
	public String getAsText() {
		// TODO Auto-generated method stub
		Event event = (Event) getValue();
		return event.getId().toString();
	}

	@Override
	public void setAsText(String text) throws IllegalArgumentException {
		// TODO Auto-generated method stub
		setValue(new Event(Integer.parseInt(text)));
	}
}

 

※  데이터 바인딩은 String <--> Object 변환만 가능하며 Object < -- > Object 변한은 불가능하다는 단점이 있다.

https://www.acmicpc.net/problem/2231

 

2231번: 분해합

어떤 자연수 N이 있을 때, 그 자연수 N의 분해합은 N과 N을 이루는 각 자리수의 합을 의미한다. 어떤 자연수 M의 분해합이 N인 경우, M을 N의 생성자라 한다. 예를 들어, 245의 분해합은 256(=245+2+4+5)이

www.acmicpc.net

 

문제


풀이


1 부터 N 까지 분해합을 확인하면 된다. 가장 작은 생성자를 구하는 것이므로 처음으로 발견한 생성자가 가장 작은 값이 된다.

 

코드


@Pathvariable란 


요청한 URL을 값으로 사용할 때 사용합니다.

 

 

 

나타나는 오류들


Required URI template variable 'url2' for method parameter type {  }is not present]

 

원인 :  @RequestMapping 주석의 요청 URL에 있는 경로 변수와 @PathVariable 주석의 메소드 변수 이름이 일치하지 않아 발생합니다.

 

해결 방안: @RequestMapping 주석과 @PathVariable 주석 사이의 경로 변수 이름은 동일해야 합니다.

 

 

 

경우 1. 요청 url에 공백이 있을 때

 

경우 2. 요청 URL과 파라미터 이름 값이 다를 때

 

 

경우 3. @PathVariable에서 value 값을 사용할 때

> 이 경우는 value 값과 요청 url 값을 같게 해줘야 합니다.

+ Recent posts