'Spring'에 해당되는 글 54건
- 2019.09.10 :: Spring - @RequestParam, @ModelAttribute의 차이점?
- 2019.08.25 :: Spring Cloud - Eureka Client 안전한 종료 방법(Discovery Client Shutdown, Spring boot graceful shutdown)
- 2019.08.17 :: Springboot - Bean Scope(싱글톤, 프로토타입) ?
- 2019.08.17 :: Spring - Field vs Constructor vs Setter Injection 그리고 순환참조(Circular Reference) 3
- 2019.08.11 :: IT책 - 스프링 퀵 스타트(채규태, 루비페이퍼)
- 2019.08.05 :: Springboot - DB Datasource 암호화/복호화(application.properties)
- 2019.06.13 :: Spring - RestTemplate Connection Pooling
- 2019.04.29 :: Spring JPA - JPA cascade 란?!
이번 포스팅은 @RequestParam과 @ModelAttribute의 차이점에 대해 다루어볼 것이다. 이번에 다루어볼 내용은 특정 유저관련 컨트롤러 코드를 작성하여 살펴볼 것이다.
작업환경은 MacOS+intelliJ로 구성하였다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
@Slf4j
@RestController
@RequestMapping("/user")
public class UserController {
@GetMapping("/insert")
public Object insertUser(@ModelAttribute("findUser") User user, BindingResult bindingResult){
if(bindingResult.hasErrors()){
log.info("binding error");
return "invalidParam";
}
if(user.getId() == 1){
user.setLastName("yoon");
user.setAge(28);
user.setLevel(Level.BASIC);
return user;
}
return null;
}
@GetMapping("/insert2")
public Object insertUser(@RequestParam int id, @RequestParam String firstName, @RequestParam String lastName){
return "RequestParamBinding";
}
}
@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
class User{
private int id;
private String firstName;
private String lastName;
private int age;
private Level level;
}
|
cs |
위와 같은 코드가 있다. 세부적인 로직은 제외하고 파라미터를 바인딩하는 부분을 집중해보자. 우선 @RequestParam과 @ModelAttribute의 파라미터 바인딩에는 큰 차이가 있다. 바로 객체로 받는냐, 혹은 쿼리스트링을 하나하나 바인딩 받느냐의 차이이다. 이것은 코드의 가독성에 아주 큰 차이가 있다. 두번째 차이점은 @ModelAttribute는 사용자가 직접 View에 뿌려질 Model객체를 직접 set하지 않아도 된다는 점이다. @ModelAttribute는 스프링이 직접 ModelMap에 객체를 넣어주기 때문이다. 이러한 바인딩 차이점 이외에 한가지 아주 큰 차이점이 있다.
매핑을 보면 @ModelAttribute에는 BindingResult라는 인자가 들어가있는 것을 볼 수 있다. 하지만 @RequestParam은 없다. 과연 무슨 말일까?
@ModelAttribute는 사실 파라미터를 검증할 수 있는 기능을 제공한다. 이 말은 파라미터 바인딩에 예외가 발생하여도 혹은 파라미터 바인딩은 문제없이 됬으나 로직처리에 적합하지 않은 파라미터가 들어오는 등 이러한 파라미터를 검증할 수 있는 기능이 있다. 만약 파라미터 바인딩에 예외가 발생하였을 때, @ModelAttribute와 @RequestParam의 차이점을 보자. 전자는 바인딩 예외를 BindingResult에 담아준다. 즉, 4xx 예외가 발생하지 않는 것이다. 하지만 @RequestParam 같은 경우 바인딩 예외가 발생하는 순간 TypeMisMatch 예외를 발생시켜 사용자에게 4xx status code를 전달한다.
그러면 개발자는 파라미터를 검증하는 로직을 컨트롤러 코드와 따로 분리하여 바인딩된 파라미터의 값의 유효성을 검사할 수 있게 해준다. 만약 @RequestParam이라면 직접 비즈니스 로직내에서 파라미터를 검증하는 코드가 들어가야 할 것이다.
바인딩 예외 처리의 차이점을 간단한 테스트 코드로 테스트 해보았다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
@SpringBootTest
@RunWith(SpringRunner.class)
public class UserControllerTest {
private static final String FINDBYID_MODELATTRIBUTE_REQUEST_URI = "/user/find";
private static final String FINDBYID_REQUESTPARAM_REQUEST_URI = "/user/find2";
private User validParamForFindByUserId ;
private MockMvc mockMvc;
@Before
public void init(){
this.mockMvc = MockMvcBuilders.standaloneSetup(new UserController()).build();
}
@Before
public void initParam(){
validParamForFindByUserId = new User(1,"yeoseong","yoon",28,Level.valueOf(1));
}
@Test
public void paramVaildationWhenInvalidInputParamWithModelAttribute() throws Exception {
MvcResult createResult = mockMvc.perform(get(FINDBYID_MODELATTRIBUTE_REQUEST_URI+"?id=abc"))
.andDo(print())
.andExpect(content().string("invalidParam"))
.andReturn()
;
}
@Test
public void paramValidationWhenInvalidInputParamWithRequestParam() throws Exception {
MvcResult createResult = mockMvc.perform(get(FINDBYID_REQUESTPARAM_REQUEST_URI+"?id=abc"))
.andDo(print())
.andExpect(status().is4xxClientError())
.andReturn()
;
}
}
|
cs |
위 테스트를 돌려보면 우리가 기대하는 바인딩 예외처리 테스트가 무사히 통과할 것이다.
'Web > Spring' 카테고리의 다른 글
| Spring - Spring Cache 추상화(스프링 캐시 추상화),@Cacheable,@CacheEvict,@CachePut (0) | 2019.09.11 |
|---|---|
| Spring - Model Validation 방법!(파라미터 Validation),@Valid (0) | 2019.09.10 |
| Springboot - Bean Scope(싱글톤, 프로토타입) ? (0) | 2019.08.17 |
| Spring - Field vs Constructor vs Setter Injection 그리고 순환참조(Circular Reference) (3) | 2019.08.17 |
| Springboot - DB Datasource 암호화/복호화(application.properties) (0) | 2019.08.05 |
2019/02/24 - [Web/Spring Cloud] - Spring Cloud - Eureka를 이용한 마이크로서비스 동적등록&탐색&부하분산처리
Spring Cloud - Eureka를 이용한 마이크로서비스 동적등록&탐색&부하분산처리
Spring Cloud - Eureka를 이용한 마이크로서비스 동적등록&탐색&부하분산처리 스프링 클라우드 유레카는 넷플릭스 OSS에서 유래됐다. 자가 등록, 동적 탐색 및 부하 분산에 주로 사용되며, 부하 분산을 위해 내부..
coding-start.tistory.com
우리는 이전 포스팅들에서 Spring Cloud를 다루어보면서 동적인 서비스 등록과 서버사이드 로드밸런싱에 중대한 역할을 하게 되는 Eureka에 대해 다루어 봤었다. 이러한 유레카를 이용하여 우리는 애플리케이션의 무중단 배포도 가능하다. 새로운 애플리케이션을 올리고 이전 버전의 애플리케이션을 죽이는 단순한 과정에서 우리는 중요한 개념을 생각해야 한다. 만약 이전 버전의 애플리케이션이 사용자의 요청을 받아 처리 중이라면? 그냥 애플리케이션을 죽이면 처리중인 요청을 끝까지 처리하지 못하고 데이터 유실이 발생할 것이다. 이럴때 우리는 우아하게 종료할 수 있는 방안이 필요하다. 예를 들면, Apache에서도 프로세스를 재시작하는 명령에 restart / graceful 명령이 존재한다. 전자는 단순히 stop&start이고 후자는 받은 요청을 모두 처리하고 종료하게 된다. 이러한 기능을 Spring boot는 어떻게 제공할까?
Actuator를 사용하면 된다. 스프링 액츄에이터는 다양하게 실행 중인 애플리케이션의 모니터링 정보 및 유용한 기능을 제공한다. 이중 shutdown 기능이 있는데, 액츄에이터의 shutdown은 graceful 하게 shutdown을 시켜준다 ! 즉, 데이터 유실 없이 안전하고 우아한 애플리케이션 종료를 제공한다.
'Web > Spring Cloud' 카테고리의 다른 글
| Spring Cloud - Zuul API gateway & Proxy !(Netflix Zuul) (0) | 2019.02.25 |
|---|---|
| Spring Cloud - Spring Cloud Bus (0) | 2019.02.24 |
| Spring Cloud - Eureka를 이용한 마이크로서비스 동적등록&탐색&부하분산처리 (0) | 2019.02.24 |
| Spring Cloud - Spring Cloud Config(스프링 클라우드 컨피그) (0) | 2019.02.23 |
스프링에서 빈을 생성할 때, 기본 전략은 모든 빈이 싱글톤으로 생성된다. 즉, 어디에서든지 빈을 주입받는 다면 동일한 빈을 주입받는 것을 보장한다. 하지만 필요에 따라서 빈 주입마다 새로운 빈을 생성해야할 필요가 있을 경우도 있다. 이럴 경우에는 빈 생성시 Scope를 prototype으로 주면 빈 주입마다 새로운 인스턴스가 생성되는 것을 보장한다. 하지만 프로토타입 빈을 사용할 경우 주의해야 할 상황이 있다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
@Component
public class ABean {
@Autowired
private BBean b;
public void bMethod() {
b.print();
}
}
@Component
@Scope("prototype")
public class BBean {
public void print() {
System.out.println("BBean !");
}
}
|
cs |
이런식으로 사용한다면 어떻게 될까? 이것은 사실 프로토타입을 쓰나마나이다. 싱글톤으로 생성된 A빈에 프로토타입 B빈을 주입해봤자 A빈은 더이상 생성되지 않기 때문에 항상 동일한 B빈을 사용하게 되는 것이다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
|
@Component
public class ABean {
@Autowired
private BBean b;
public void print() {
System.out.println(b.hashCode());
}
}
@Component
@Scope("prototype")
public class BBean {
}
@Component
public class CBean {
@Autowired
private ABean a;
public void print() {
a.print();
}
}
@Component
public class DBean {
@Autowired
private ABean a;
public void print() {
a.print();
}
}
@SpringBootApplication
public class CircularReferenceApplication implements CommandLineRunner{
@Autowired private CBean c;
@Autowired private DBean d;
public static void main(String[] args) {
SpringApplication.run(CircularReferenceApplication.class, args);
}
@Override
public void run(String... args) throws Exception {
c.print();
d.print();
}
}
|
cs |
위 코드를 실행시켜보자. 프로토타입 빈으로 등록된 B빈이지만 항상 어디서든 동일한 해시코드를 반환한다. 즉, 프로토타입빈을 사용하기 위해서는 아래와 같이 사용하자.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
@Service
public class BeanUtil implements ApplicationContextAware {
private static ApplicationContext context;
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
context = applicationContext;
}
public static <T> T getBean(Class<T> beanClass) {
return context.getBean(beanClass);
}
}
@Component
public class ABean {
public void print() {
BBean b = BeanUtil.getBean(BBean.class);
System.out.println(b.hashCode());
}
}
|
cs |
ApplicationContext 객체에서 직접 빈을 가져와서 메소드 내부에서 사용하도록 하자. 이제는 매번 다른 B빈의 해시코드를 반환할 것이다.
2019/02/25 - [Web/Spring] - Spring - ApplicationContext,ApplicationContextAware, 빈이 아닌 객체에 빈주입할때!
Spring - ApplicationContext,ApplicationContextAware, 빈이 아닌 객체에 빈주입할때!
Spring - ApplicationContext,ApplicationContextAware, 빈이 아닌 객체에 빈주입할때! @Autuwired,@Inject 등의 어노테이션으로 의존주입을 하기 위해서는 해당 객체가 빈으로 등록되어 있어야만 가능하다. 사실..
coding-start.tistory.com
'Web > Spring' 카테고리의 다른 글
| Spring - Model Validation 방법!(파라미터 Validation),@Valid (0) | 2019.09.10 |
|---|---|
| Spring - @RequestParam, @ModelAttribute의 차이점? (0) | 2019.09.10 |
| Spring - Field vs Constructor vs Setter Injection 그리고 순환참조(Circular Reference) (3) | 2019.08.17 |
| Springboot - DB Datasource 암호화/복호화(application.properties) (0) | 2019.08.05 |
| Springboot - Logback 설정 방법 !(logback-spring.xml) (1) | 2019.06.15 |
오늘 포스팅할 내용은 필드,생성자,세터 의존주입에 대한 내용이다. 우리가 보통 생각하는 의존주입은 무엇인가? 혹은 우리가 평소에 사용하는 의존주입의 방식은 무엇인가? 한번 생각해보고 각각에 대한 내용을 다루어보자.
<Field Injection>
|
1
2
3
4
5
6
7
8
9
10
11
|
@Component
public class ABean {
@Autowired
private BBean b;
public void bMethod() {
b.print();
}
}
|
cs |
보통 위와 같이 필드에 의존주입할 빈을 선언하고 @Autowired를 붙여 빈 주입을 한다.
<Constructor Injection>
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
@Component
public class ABean {
private BBean b;
public ABean(BBean b) {
this.b=b;
}
public void bMethod() {
b.print();
}
}
|
cs |
생성자를 위한 빈 주입은 위와 같이 생성자의 매개변수로 의존 주입할 빈을 매개변수로 넣어준다. 스프링 4.3 버전 이후로는 생성자 의존주입에 @Autowired를 넣을 필요는 없다.
<Setter Injection>
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
@Component
public class ABean {
private BBean b;
@Autowired
public void setB(BBean b) {
this.b = b;
}
public void bMethod() {
b.print();
}
}
|
cs |
세터를 이용한 빈주입이다. 의존 주입할 빈 객체에 대한 Setter를 만들어주고 @Autowired를 붙여준다.
지금까지 3개의 의존주입 방법을 다루어보았다. 아직은 똑같은 결과물을 내는 다른 방법이라는 것만 느껴진다. 그렇다면 특정 상황을 연출해보자. 바로 Circular Reference(순환참조)인 경우이다. 3가지 의존주입 방법을 모두 활용하여 순환참조 상황을 재연해보자.
순환참조
-A빈이 있고 B빈이 있는데, 각각 서로가 서로를 참조하고 있는 상황에서 발생한다. 이러한 상황에서 A빈이 메모리에 올라가기 전에 B빈이 A빈을 의존주입하는 상황이나 혹은 그 반대의 경우 문제가 발생한다.
<Field Injection>
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
@Component
public class ABean {
@Autowired
private BBean b;
public void bMethod() {
b.print();
}
public void print() {
System.out.println("ABean !");
}
}
@Component
public class BBean {
@Autowired
private ABean a;
public void aMethod() {
a.print();
}
public void print() {
System.out.println("BBean !");
}
}
@SpringBootApplication
public class CircularReferenceApplication implements CommandLineRunner{
@Autowired
private ABean a;
@Autowired
private BBean b;
public static void main(String[] args) {
SpringApplication.run(CircularReferenceApplication.class, args);
}
@Override
public void run(String... args) throws Exception {
a.bMethod();
b.aMethod();
}
}
|
cs |
위는 순환참조 상황을 필드 의존주입으로 재연해본 것이다. 과연 결과를 어떻게 나올 것인가?
<Constructor Injection>
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
@Component
public class ABean {
private BBean b;
public ABean(BBean b) {
this.b=b;
}
public void bMethod() {
b.print();
}
public void print() {
System.out.println("ABean !");
}
}
@Component
public class BBean {
private ABean a;
public BBean(ABean a) {
this.a=a;
}
public void aMethod() {
a.print();
}
public void print() {
System.out.println("BBean !");
}
}
@SpringBootApplication
public class CircularReferenceApplication implements CommandLineRunner{
@Autowired
private ABean a;
@Autowired
private BBean b;
public static void main(String[] args) {
SpringApplication.run(CircularReferenceApplication.class, args);
}
@Override
public void run(String... args) throws Exception {
a.bMethod();
b.aMethod();
}
}
|
cs |
순환참조 상황을 생성자 의존주입으로 재연해보았다. 이 또한 어떠한 결과가 발생할까?
<Setter Injection>
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
@Component
public class ABean {
private BBean b;
@Autowired
public void setB(BBean b) {
this.b = b;
}
public void bMethod() {
b.print();
}
public void print() {
System.out.println("ABean !");
}
}
@Component
public class BBean {
private ABean a;
@Autowired
public void setA(ABean a) {
this.a = a;
}
public void aMethod() {
a.print();
}
public void print() {
System.out.println("BBean !");
}
}
@SpringBootApplication
public class CircularReferenceApplication implements CommandLineRunner{
@Autowired
private ABean a;
@Autowired
private BBean b;
public static void main(String[] args) {
SpringApplication.run(CircularReferenceApplication.class, args);
}
@Override
public void run(String... args) throws Exception {
a.bMethod();
b.aMethod();
}
}
|
cs |
마지막으로 세터 의존주입을 이용하여 순환참조 상황을 재연하였다. 3가지 상황에서의 각각의 결과는 어떻게 될까?
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
=>Field Injection
BBean !
ABean !
=>Constructor Injection
***************************
APPLICATION FAILED TO START
***************************
Description:
The dependencies of some of the beans in the application context form a cycle:
circularReferenceApplication (field private com.example.demo.ABean com.example.demo.CircularReferenceApplication.a)
┌─────┐
| ABean defined in file [/Users/yun-yeoseong/eclipse-study/circular-reference/target/classes/com/example/demo/ABean.class]
↑ ↓
| BBean defined in file [/Users/yun-yeoseong/eclipse-study/circular-reference/target/classes/com/example/demo/BBean.class]
└─────┘
=>Setter Injection
BBean !
ABean !
|
cs |
결과는 위와 같다. 어떻게 된것일까? 다 같은 결과를 내는 의존주입인데, 단 하나 생성자 의존주입에서는 애플리케이션이 기동되지 못하고 순환참조 관련 예외가 발생하였다. 이유는 3가지의 객체의 라이프사이클을 떠올려보자. 필드,세터 의존주입은 필드&세터 메소드를 이용하여 의존주입을 하게 된다. 그렇다면 전제가 무엇일까? 바로 해당 객체가 메모리에 적재된 후에 빈을 주입하게 되는 것이다. 그렇다면 생성자 의존주입은 어떨까? 생성자 의존주입은 객체를 생성자로 생성하는 시점에 필요한 빈들을 의존주입한다. 즉, 객체를 생성하는 동시에 빈을 주입하는 것 그리고 객체를 이미 생성한 이후에 빈을 주입하는 것의 차이가 되는 것이다. 위에서 순환참조에 대해 간단히 설명을 하였다. 다시 한번 떠올려보자.
|
1
2
3
4
5
|
┌─────┐
| ABean defined in file [/Users/yun-yeoseong/eclipse-study/circular-reference/target/classes/com/example/demo/ABean.class]
↑ ↓
| BBean defined in file [/Users/yun-yeoseong/eclipse-study/circular-reference/target/classes/com/example/demo/BBean.class]
└─────┘
|
cs |
위와 같은 예외가 발생한 이유는 A는 B를 필요로하고 B도 A를 필요로 할때 발생하는 문제인데, 단순 서로를 참조하기 때문의 문제가 아니라 서로 참조하는 객체가 생성되지도 않았는데, 그 빈을 참조하기 때문에 발생하는 예외인 것이다. 즉, 순환참조는 당연히 생성자 의존주입에서만 문제가 될 수 밖에 없는 것이다. 생성자 의존주입은 빈 주입을 객체 생성시점에 주입하기 때문이다.
여기서 생각해 볼 것이 있다. 그러면 순환참조를 피하기 위해 필드 혹은 세터 의존주입을 사용해야 되는 것인가? 답은 아니다. 순환참조를 유발하는 객체 설계 자체가 잘못 설계된 객체임을 생각해볼 수 있다. 순환참조를 필드,세터 의존주입으로 피하는 것은 단순히 잘못 설계된 객체를 억지로 문제를 회피하여 사용하는 것은 아닌가 생각해볼 필요가 있다는 것이다.
객체지향 설계에서 객체의 의존에 순환관계가 있다면 잘못 설계된 객체인지 살펴볼 필요가 있다. 아니다. 왠만하면 리팩토링하자 !
<Field Injection vs Constructor Injection>
1.단일 책임의 원칙 위반
의존성을 주입하기가 쉽다. @Autowired 선언 아래 3개든 10개든 막 추가할 수 있으니 말이다. 여기서 Constructor Injection을 사용하면 다른 Injection 타입에 비해 위기감 같은 걸 느끼게 해준다. Constructor의 파라미터가 많아짐과 동시에 하나의 클래스가 많은 책임을 떠안는다는 걸 알게된다. 이때 이러한 징조들이 리팩토링을 해야한다는 신호가 될 수 있다.
2.의존성이 숨는다.
DI(Dependency Injection) 컨테이너를 사용한다는 것은 클래스가 자신의 의존성만 책임진다는게 아니다. 제공된 의존성 또한 책임진다. 그래서 클래스가 어떤 의존성을 책임지지 않을 때, 메서드나 생성자를 통해(Setter나 Contructor) 확실히 커뮤니케이션이 되어야한다. 하지만 Field Injection은 숨은 의존성만 제공해준다.
3.DI 컨테이너의 결합성과 테스트 용이성
DI 프레임워크의 핵심 아이디어는 관리되는 클래스가 DI 컨테이너에 의존성이 없어야 한다. 즉, 필요한 의존성을 전달하면 독립적으로 인스턴스화 할 수 있는 단순 POJO여야한다. DI 컨테이너 없이도 유닛테스트에서 인스턴스화 시킬 수 있고, 각각 나누어서 테스트도 할 수 있다. 컨테이너의 결합성이 없다면 관리하거나 관리하지 않는 클래스를 사용할 수 있고, 심지어 다른 DI 컨테이너로 전환할 수 있다.
하지만, Field Injection을 사용하면 필요한 의존성을 가진 클래스를 곧바로 인스턴스화 시킬 수 없다.
4.불변성(Immutability)
Constructor Injection과 다르게 Field Injection은 final을 선언할 수 없다. 그래서 객체가 변할 수 있다.
5.순환 의존성
Constructor Injection에서 순환 의존성을 가질 경우 BeanCurrentlyCreationExeption을 발생시킴으로써 순환 의존성을 알 수 있다.
<Setter Injection vs Construct Injection>
1.Setter Injection
Setter Injection은 선택적인 의존성을 사용할 때 유용하다. 상황에 따라 의존성 주입이 가능하다. 스프링 3.x 다큐멘테이션에서는 Setter Injection을 추천했었다.
2.Constructor Injection
Constructor Injection은 필수적인 의존성 주입에 유용하다. 게다가 final을 선언할 수 있으므로 객체가 불변하도록 할 수 있다. 또한 위에서 언급했듯이 순환 의존성도 알 수 있다. 그로인해 나쁜 디자인 패턴인지 아닌지 판단할 수 있다.
스프링 4.3버전부터는 클래스를 완벽하게 DI 프레임워크로부터 분리할 수 있다. 단일 생성자에 한해 @Autowired를 붙이지 않아도 된다.(완전 편한데?!) 이러한 장점들 때문에 스프링 4.x 다큐멘테이션에서는 더이상 Setter Injection이 아닌 Constructor Injection을 권장한다. 굳이 Setter Injection을 사용한다면, 합리적인 디폴트를 부여할 수 있고 선택적인(optional) 의존성을 사용할 때만 사용해야한다고 말한다. 그렇지 않으면 not-null 체크를 의존성을 사용하는 모든 코드에 구현해야한다.
'Web > Spring' 카테고리의 다른 글
| Spring - @RequestParam, @ModelAttribute의 차이점? (0) | 2019.09.10 |
|---|---|
| Springboot - Bean Scope(싱글톤, 프로토타입) ? (0) | 2019.08.17 |
| Springboot - DB Datasource 암호화/복호화(application.properties) (0) | 2019.08.05 |
| Springboot - Logback 설정 방법 !(logback-spring.xml) (1) | 2019.06.15 |
| Spring - RestTemplate Connection Pooling (0) | 2019.06.13 |
필자가 처음 스프링을 공부하기 위해 구입했던 책은 토비의 스프링이었다. 하지만 초급자에게 토비의 스프링을 완독하기란 쉽지 않을 일이였기에, 간단하게 스프링을 공부하기 위해 책을 찾던중 스프링 퀵 스타트라는 책을 알게되었다. 이 책은 스프링을 잘 모르고 처음 공부하는 사람에게 아주 좋은 책인 것 같다. 너무 깊지도 얕지도 않은 많이 사용하는 기술들을 이해하기 쉽게 알려주는 책이다.
'일상&기타 > 책' 카테고리의 다른 글
| IT책 - 마스터링 스프링 클라우드(피요트르 민코프스키, 위키북스) (0) | 2019.08.11 |
|---|---|
| IT책 - 스프링 5.0 마이크로서비스 2/e(라제시 RV, 에이콘) (0) | 2019.08.11 |
| IT책 - 스프링 부트로 배우는 자바 웹 개발(윤석진, 제이펍) (0) | 2019.08.11 |
| IT책 - 토비의 스프링3.1(이일민, 에이콘) (0) | 2019.08.11 |
| IT책 - 시작하세요! 스프링 4 프로그래밍(애쉬쉬 사린, 제이샤마, 위키북스) (0) | 2019.08.11 |
이번 포스팅에서 다루어볼 내용은 spring boot project에서 DB Access관련 설정을 application.properties에 설정 해 놓는데, 기존처럼 평문으로 username/password를 넣는 것이 아니라 특정 알고리즘으로 암호화된 문자열을 넣고 애플리케이션 스타트업 시점에 복호화하여 DB Access를 하는 것입니다. 바로 예제로 들어가겠습니다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
package com.example.demo;
import java.security.Key;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Base64;
import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;
import org.junit.Test;
public class EncryptTest {
@Test
public void encrypt() throws Exception {
String str = "ENCRYPT!@1234";
String encStr = encAES(str);
System.out.println(encStr);
System.out.println(decAES(encStr));
}
public Key getAESKey() throws Exception {
String iv;
Key keySpec;
String key = "encryption!@1234";
iv = key.substring(0, 16);
byte[] keyBytes = new byte[16];
byte[] b = key.getBytes("UTF-8");
int len = b.length;
if (len > keyBytes.length) {
len = keyBytes.length;
}
System.arraycopy(b, 0, keyBytes, 0, len);
keySpec = new SecretKeySpec(keyBytes, "AES");
return keySpec;
}
// 암호화
public String encAES(String str) throws Exception {
Key keySpec = getAESKey();
String iv = "0987654321654321";
Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding");
c.init(Cipher.ENCRYPT_MODE, keySpec, new IvParameterSpec(iv.getBytes("UTF-8")));
byte[] encrypted = c.doFinal(str.getBytes("UTF-8"));
String enStr = new String(Base64.getEncoder().encode(encrypted));
return enStr;
}
// 복호화
public String decAES(String enStr) throws Exception {
Key keySpec = getAESKey();
String iv = "0987654321654321";
Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding");
c.init(Cipher.DECRYPT_MODE, keySpec, new IvParameterSpec(iv.getBytes("UTF-8")));
byte[] byteStr = Base64.getDecoder().decode(enStr.getBytes("UTF-8"));
String decStr = new String(c.doFinal(byteStr), "UTF-8");
return decStr;
}
}
|
cs |
위의 소스는 암복호화 단위테스트 코드입니다. AES-128 방식으로 암복호화하였으며 CBC 방식으로 진행하였습니다. 암호화 알고리즘에 대해서는 추후 포스팅하도록 하겠습니다.
|
1
2
3
|
#AES128_Encrypt
spring.datasource.username=T7Me97L7JW9YXubNVtNfpQ==
spring.datasource.password=/Wm/Ubs7CniQuA+5Mzq7Qg==
|
cs |
위는 암호화된 형태소 Datasource 정보를 넣은 것입니다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
|
package com.example.demo.config;
import java.security.Key;
import java.util.Base64;
import java.util.Properties;
import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.env.EnvironmentPostProcessor;
import org.springframework.core.env.ConfigurableEnvironment;
import org.springframework.core.env.PropertiesPropertySource;
public class EncryptEnvPostProcessor implements EnvironmentPostProcessor {
@Override
public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) {
Properties props = new Properties();
try {
props.put("spring.datasource.password", decAES(environment.getProperty("spring.datasource.password")));
props.put("spring.datasource.username", decAES(environment.getProperty("spring.datasource.username")));
} catch (Exception e) {
System.out.println("DB id/password decrypt fail !");
}
environment.getPropertySources().addFirst(new PropertiesPropertySource("myProps", props));
}
public Key getAESKey() throws Exception {
String iv;
Key keySpec;
String key = "encryption!@1234";
iv = key.substring(0, 16);
byte[] keyBytes = new byte[16];
byte[] b = key.getBytes("UTF-8");
int len = b.length;
if (len > keyBytes.length) {
len = keyBytes.length;
}
System.arraycopy(b, 0, keyBytes, 0, len);
keySpec = new SecretKeySpec(keyBytes, "AES");
return keySpec;
}
// 암호화
public String encAES(String str) throws Exception {
Key keySpec = getAESKey();
String iv = "0987654321654321";
Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding");
c.init(Cipher.ENCRYPT_MODE, keySpec, new IvParameterSpec(iv.getBytes("UTF-8")));
byte[] encrypted = c.doFinal(str.getBytes("UTF-8"));
String enStr = new String(Base64.getEncoder().encode(encrypted));
return enStr;
}
// 복호화
public String decAES(String enStr) throws Exception {
Key keySpec = getAESKey();
String iv = "0987654321654321";
Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding");
c.init(Cipher.DECRYPT_MODE, keySpec, new IvParameterSpec(iv.getBytes("UTF-8")));
byte[] byteStr = Base64.getDecoder().decode(enStr.getBytes("UTF-8"));
String decStr = new String(c.doFinal(byteStr), "UTF-8");
return decStr;
}
}
|
cs |
위 소스는 springboot application 기동 시점에 암호화된 username/password를 복호화하여 Datasource 객체를 생성하기 위한 후처리 프로세서입니다. EnvironmentPostProcessor라는 인터페이스를 구현한 클래스를 하나 생성하여 오버라이딩된 메소드에 복호화하는 로직을 구현해주시면 됩니다.
여기서 중요한 것은 그냥 후처리 프로세서를 등록하면 끝나는 것이 아니라 설정 파일을 넣어 주어야 합니다.
src/main/resources/META-INF/spring.factories 파일을 생성하여 아래와 같은 정보를 기입해줍니다.
|
1
2
|
# post processor 적용
org.springframework.boot.env.EnvironmentPostProcessor=com.example.demo.config.EncryptEnvPostProcessor
|
cs |
EncryptEnvPostProcessor라는 클래스의 패키지네임을 포함한 Full Path를 해당 설정파일에 기입해주시면 됩니다.
여기까지 application.properties에 암호화된 정보를 넣어 복호화하는 예제를 진행해봤습니다. 사실 Datasource 외에도 다른 설정파일에도 적용가능한 예제입니다. 활용하시길 바랍니다!
'Web > Spring' 카테고리의 다른 글
| Springboot - Bean Scope(싱글톤, 프로토타입) ? (0) | 2019.08.17 |
|---|---|
| Spring - Field vs Constructor vs Setter Injection 그리고 순환참조(Circular Reference) (3) | 2019.08.17 |
| Springboot - Logback 설정 방법 !(logback-spring.xml) (1) | 2019.06.15 |
| Spring - RestTemplate Connection Pooling (0) | 2019.06.13 |
| Spring - JSON to Object(Object to JSON) Converting Gson ! (0) | 2019.05.30 |
오늘 포스팅할 내용은 Spring의 RestTemplate입니다. 우선 RestTemplate란 Spring 3.0부터 지원하는 Back End 단에서 Http 통신에 유용하게 쓰이는 템플릿 객체이며, 복잡한 HttpClient 사용을 한번 추상화하여 Http 통신사용을 단순화한 객체입니다. 즉, HttpClient의 사용에 있어 기계적이고 반복적인 코드들을 한번 랩핑해서 손쉽게 사용할 수 있게 해줍니다. 또한 json,xml 포멧의 데이터를 RestTemplate이 직접 객체에 컨버팅해주기도 합니다.
이렇게 사용하기 편한 RestTemplate에서도 하나 짚고 넘어가야할 점이 있습니다. RestTemplate 같은 경우에는 Connection Pooling을 직접적으로 지원하지 않기 때문에 매번 RestTemplate를 호출할때마다, 로컬에서 임시 TCP 소켓을 개방하여 사용합니다. 또한 이렇게 사용된 TCP 소켓은 TIME_WAIT 상태가 되는데, 요청량이 엄청 나게 많아진다면 이러한 상태의 소켓들은 재사용 될 수 없기 때문에 응답이 지연이 될것입니다. 하지만 이러한 RestTemplate도 Connection Pooling을 이용할 수 있는데 이것은 바로 RestTemplate 내부 구성에 의해 가능합니다. 바로 내부적으로 사용되는 HttpClient를 이용하는 것입니다. 바로 예제 코드로 들어가겠습니다.
우선 Connection pool을 적용하기 위한 HttpClientBuilder를 사용하기 위해서는 dependency 라이브러리가 필요하다.
compile group: 'org.apache.httpcomponents', name: 'httpclient', version: '4.5.6'
각자 필요한 버전을 명시해서 의존성을 추가해준다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
/*
* Connection Pooling을 적용한 RestTemplate
*/
@Bean(name="restTemplateClient")
public RestTemplate restClient() {
HttpComponentsClientHttpRequestFactory httpRequestFactory = new HttpComponentsClientHttpRequestFactory();
/*
* 타임아웃 설정
*/
//httpRequestFactory.setConnectTimeout(timeout);
//httpRequestFactory.setReadTimeout(timeout);
//httpRequestFactory.setConnectionRequestTimeout(connectionRequestTimeout);
HttpClient httpClient = HttpClientBuilder.create()
.setMaxConnTotal(150)
.setMaxConnPerRoute(50)
.build();
httpRequestFactory.setHttpClient(httpClient);
return new RestTemplate(httpRequestFactory);
}
|
cs |
위에 코드를 보면 최대 커넥션 수(MaxConnTotal)를 제한하고 IP,포트 1쌍 당 동시 수행할 연결 수(MaxConnPerRoute)를 제한하는 설정이 포함되어있습니다. 이런식으로 최대 커넥션 수를 150개로 제한하여 150개의 자원내에서 모든 일을 수행하게 되는 것입니다. 마치 DB의 Connection Pool 과 비슷한 역할이라고 보시면 됩니다.(물론 같지는 않음.) 그리고 RestTemplate은 Multi Thread 환경에서 safety 하기 때문에 빈으로 등록하여 가져다 쓰도록 하였습니다.
마지막으로 구글링을 하던 도중에 Keep-alive 활성화가 되야지만 HttpClient의 Connection Pooling 지원이 가능하다고 나와있습니다. 기본적으로 HTTP1.1은 Keep-alive가 활성화되어 있지만 이부분은 더 깊게 알아봐야할 점인것 같습니다. 만약 해당 부분에 대해 아시는 분은 꼭 댓글에 코멘트 부탁드리겠습니다.
'Web > Spring' 카테고리의 다른 글
| Springboot - DB Datasource 암호화/복호화(application.properties) (0) | 2019.08.05 |
|---|---|
| Springboot - Logback 설정 방법 !(logback-spring.xml) (1) | 2019.06.15 |
| Spring - JSON to Object(Object to JSON) Converting Gson ! (0) | 2019.05.30 |
| Spring - ModelMapper란? (2) | 2019.04.10 |
| Spring boot - Redis를 이용한 HttpSession (1) | 2019.04.02 |
오늘 포스팅할 내용은 간단히 JPA의 cascade 기능이다. 이전 포스팅 중에 해당 내용에 대해 포스팅한적이 있지만 조금 부족한 것같아서 다시 한번 정리할겸 글을 남긴다.
영속성 전이(cascade)란 쉽게 말해 부모 엔티티가 영속화될때, 자식 엔티티도 같이 영속화되고 부모 엔티티가 삭제 될때, 자식 엔티티도 삭제되는 등 부모의 영속성 상태가 전이되는 것을 이야기한다. 영속성전이의 종류로는 ALL, PERSIST, DETACH, REFRESH, MERGE, REMOVE등이 있다. 이름만 봐도 어디까지 영속성이 전이되는지 확 눈에 보일 것이다. 여기서는 별도로 각각을 설명하지는 않는다.
오늘의 상황 : A와 B라는 엔티티가 존재하고, 두 엔티티의 관계는 @ManyToMany 관계이다. 이 관계는 중간에 Bridge 테이블을 두어 @OneToMany<->@ManyToOne @OneToMany<->@ManyToOne 관계로 매핑하였다. 그리고 C라는 엔티티는 A엔티티와 @ManyToOne 관계이다. 이렇게 여러개가 조인이 걸려있는 상황에서 cascade를 이용한 PERSIST 예제를 한번 짜보았다.
<AEntity Class>
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
@Entity
@Table(name = "TB_A")
@Getter
@Setter
@ToString
public class AEntity {
@Id
@Column(name = "A_ID")
@GeneratedValue(strategy=GenerationType.TABLE, generator = "SEQ_GENERATOR")
@TableGenerator(
name="SEQ_GENERATOR",
table="MY_SEQUENCE",
pkColumnName="SEQ_NAME", //MY_SEQUENCE 테이블에 생성할 필드이름(시퀀스네임)
pkColumnValue="A_SEQ", //SEQ_NAME이라고 지은 칼럼명에 들어가는 값.(키로 사용할 값)
allocationSize=1
)
private Long id;
private String name;
@OneToMany(mappedBy="a",cascade=CascadeType.ALL)
private List<CEntity> cList = new ArrayList<>();
@OneToMany(mappedBy = "aEntity",fetch=FetchType.EAGER,cascade=CascadeType.ALL)
private List<BridgeEntity> bridges;
}
|
cs |
<BEntity class>
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
@Entity
@Table(name = "TB_B")
@Getter
@Setter
@ToString
public class BEntity {
@Id
@Column(name = "B_ID")
@GeneratedValue(strategy=GenerationType.TABLE, generator = "SEQ_GENERATOR")
@TableGenerator(
name="SEQ_GENERATOR",
table="MY_SEQUENCE",
pkColumnName="SEQ_NAME", //MY_SEQUENCE 테이블에 생성할 필드이름(시퀀스네임)
pkColumnValue="B_SEQ", //SEQ_NAME이라고 지은 칼럼명에 들어가는 값.(키로 사용할 값)
allocationSize=1
)
private Long id;
private String name;
@OneToMany(mappedBy = "bEntity")
private List<BridgeEntity> bridges;
}
|
cs |
<CEntity class>
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
@Entity
@Table(name = "TB_C")
@Getter
@Setter
@ToString
public class CEntity {
@Id
@Column(name = "C_ID")
@GeneratedValue(strategy=GenerationType.TABLE, generator = "SEQ_GENERATOR")
@TableGenerator(
name="SEQ_GENERATOR",
table="MY_SEQUENCE",
pkColumnName="SEQ_NAME", //MY_SEQUENCE 테이블에 생성할 필드이름(시퀀스네임)
pkColumnValue="C_SEQ", //SEQ_NAME이라고 지은 칼럼명에 들어가는 값.(키로 사용할 값)
allocationSize=1
)
private Long id;
private String name;
@ManyToOne
@JoinColumn(name="A_ID", nullable=false)
private AEntity a;
}
|
cs |
<BridgeEntity class>
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
@Entity
@Table(name = "TB_BRIDGE")
@Getter
@Setter
@ToString
public class BridgeEntity {
@Id
@Column(name = "BRIDGE_ID")
@GeneratedValue(strategy=GenerationType.TABLE, generator = "SEQ_GENERATOR")
@TableGenerator(
name="SEQ_GENERATOR",
table="MY_SEQUENCE",
pkColumnName="SEQ_NAME", //MY_SEQUENCE 테이블에 생성할 필드이름(시퀀스네임)
pkColumnValue="BRIDGE_SEQ", //SEQ_NAME이라고 지은 칼럼명에 들어가는 값.(키로 사용할 값)
allocationSize=1
)
private Long id;
@ManyToOne
@JoinColumn(name = "A_ID")
private AEntity aEntity;
@ManyToOne
@JoinColumn(name = "B_ID")
private BEntity bEntity;
}
|
cs |
<A,B Entity Repository class>
|
1
2
3
4
5
6
7
|
public interface AEntityRepository extends JpaRepository<AEntity, Long>{
}
public interface BEntityRepository extends JpaRepository<BEntity, Long>{
}
|
cs |
테스트 상황 : A,B,C,BridgeEntity 모두 데이터를 persist 하는 상황이다. 그럼 여기서 생각해야 할것이 있다. 우선 C의 부모는 A이다. 즉, A 엔티티가 persist될때 C 자식 엔티티까지 persist되도록 영속성 전이기능을 이용하면 된다. 그렇다면 A,B,Bridge 세개의 관계는 어떻게 될까? 우선 조건이 있다. A,B,Bridge 관계에서 Bridge엔티티가 외래키의 주인이다. 이 말은 즉슨, Bridge 엔티티가 persist 되기 전에 A,B모두가 영속화된 상태여야하는 것이다. 예제는 아래와 같은 시나리오로 테스트했다.
1)B 엔티티 영속화 ->2)A 엔티티의 영속화 + Bridge 엔티티 영속성전이
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
@RunWith(SpringRunner.class)
@SpringBootTest
public class SpringDataJpaTestApplicationTests {
@Autowired AEntityRepository aRepository;
@Autowired BEntityRepository bRepository;
@Test
public void contextLoads() {
AEntity a = new AEntity();
a.setName("A");
BEntity b = new BEntity();
b.setName("B");
IntStream.rangeClosed(0, 9).forEach((i)->{
CEntity c = new CEntity();
c.setName(i+"");
a.getCList().add(c);
});
a.getCList().stream().forEach((c)->{
c.setA(a);
});
BridgeEntity bridge = new BridgeEntity();
bridge.setBEntity(bRepository.save(b));
bridge.setAEntity(a);
a.setBridges(Arrays.asList(bridge));
aRepository.save(a);
}
}
|
cs |
중요한 것이 있다. 부모 엔티티가 영속화되는 동시에 자식 엔티티가 영속화되게 영속성 전이를 이용하기 위해서는 반드시 자식 객체에 부모객체를 set해주어야 하는 점이다. 만약 부모엔티티를 자식 엔티티에 set해주지 않으면 외래키에 null값이 채워질 것이다.
결과
=>
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
A_ID NAME
25 A
B_ID NAME
21 B
C_ID NAME A_ID
63 c-0 25
64 c-1 25
65 c-2 25
66 c-3 25
67 c-4 25
68 c-5 25
69 c-6 25
70 c-7 25
71 c-8 25
72 c-9 25
BRIDGE_ID A_ID B_ID
21 25 21
|
cs |
'Web > JPA' 카테고리의 다른 글
| JPA - LazyInitializationException No Session(다중 스레드 트랜잭션,Multi Thread Transaction) (1) | 2019.05.29 |
|---|---|
| JPA - 영속성 컨텍스트와 JPQL (0) | 2019.02.12 |
| JPA - JPAQuery와 Q클래스 (0) | 2019.02.11 |
| JPA - NativeQuery ( SQL ) 네이티브 SQL 사용하기! (0) | 2019.02.11 |
| JPA - QueryDSL, JPQL Query Builder Class (0) | 2019.02.11 |