@ModelAttribute, Controller 메소드에 붙였을때

JAVA/Spring|2019. 5. 20. 18:41

@ModelAttribute, Controller 메소드에 붙였을때 요청이 들어오면 들어온 요청 Model에 메소드 리턴값이

들어오는것을 확인할 수 있다.

 

Object dutchMap = model.asMap().get("dutchMap");

@ModelAttribute("dutchMap")
	public Map<String,DutchDao> getDutchMap(){
		Map<String,DutchDao> map = new HashMap<>();
		map.put("k11", new DutchDao());
		map.put("k12", new DutchDao());
		map.put("k13", new DutchDao());
		return map;
	}

그런데 하나 궁금점

 

위에 getDutchMap()의 결과인 Map<String,DutchDao>값을

Controller 생성 초기에 bean으로 등록해서 가지고(캐싱하고) 있을까?

 

아니면 매번 요청마다 getDutchMap()을 부르게 될까?

 

확인 방법은 간단하게 getDutchMap()을 break point를 찍고 확인해보니..

 

요청마다 getDutchMap() 를 부르고 있었다..;;;

 

실시간으로 매번 생성해서 model에 세팅하는 용도라면 적절할지 모르겠지만..

모든 요청마다 매번 메소드 불리기 때문에 주의해서 사용해야 겠다...

 

 

 

 

댓글()

[Spring] ApplicationEventPublisher, AbstractApplicationEventMulticaster

JAVA/Spring|2019. 4. 30. 19:00

지난번 글에서 Spring 에서 Event를 publish 할때

TaskExecutor가 설정되어있지 않은 경우 publish 하는 스레드에서 이벤트핸들러들을 부른다고 했다.

https://meteorkor.tistory.com/entry/ApplicationEventPublisher

 

Spring Event ApplicationEventPublisher

Spring에 Event 처리하는 부분이 있길래 의문점이 조금 생겨 코드를 살펴 봤다 물론 동작은 각 설정에 따라 변경될수 있겠지만 기본 설정(가능한 설정을 손 안댄 상태에서)에서 어떻게 동작하는가? "이벤트별 블럭..

meteorkor.tistory.com

TaskExecutor를 설정하면 당연히 설정된 TaskExecutor에 이벤트 수행을 위임하게 될것이다

그렇다면 TaskExecutor를 어디에 어떻게 설정 해야 할까?

 

일단 샘플로 해보려던건 이벤트를 publisher가 아니라 Event만 처리하는 단일 스레드를 만들어 처리하는 것!

 

역시나 코드를 까봐야 알수 있는데 

ApplicationEventPublisher 에 publishEvent(event)를 쭉 타고 가면

AbstractApplicationContext에 publishEvent(Object event, ResolvableType type) 쪽에 도달할 수 있다.

보면 결국 ApplicationEventMulticaster를 구해서 multicastEvent()를 부르는걸 볼수 있고

그안에서 결국 지난번 글에서 말한대로 Executor가 있으면 Executor를 통해 수행하고 없으면 invokeListener()를 통해 로컬 콜을 수행하는걸 볼수 있다.

 

위에 getTaskExecutor()를 보면  결국 ApplicationEventMulticaster가 들고 있는 TaskExecutor를 사용하는것을 확인할수 있었다

 

그럼 ApplicationEventMulticaster 는 어디서 TaskExecutor를 가져올까..?

빈으로 TaskExecutor를 등록하면 타입으로 가져와서 쓰려나..?

 

그런데 아무리 TaskExecutor 타입의 빈을 등록해도 ApplicationEventMulticaster 안에 TaskExecutor는 null이였다..

 

그럼 ApplicationEventMulticaster 타입의 빈을 등록해두면 ApplicationEventMulticaster을 등록한 빈으로 사용하려나? 했는데 마찬가지로 안됬다

 

결국 찾은 방법은

빈이름을 주고 등록하는것

"applicationEventMulticaster" 이름으로 고정되어있나보다..

 

 

그래서 위와같이 빈 이름을 주고 빈등록을 하면 위 구현체를 사용해서 Event를 Multicasting 하는것을 볼 수 있었다.

 

 

 

 

댓글()

[Spring] 인트로덕션(introduction), @DeclareParents

카테고리 없음|2019. 4. 29. 18:30

책을 보다 잘 모르던 기능이 보여서 정리 차원에서 글을 남긴다.

 

"인트로덕션"

어노테이션은 @DeclareParents 를 사용하며

다중 상속을 사용할 수  없는 상황에서 다중 상속처럼 여러 구현체를 사용할 수 있도록 해주는 기능

(사실 타겟 클래스에 설정된 인터페이스를 모두 implements 하게 하고 구현할 내용에 인터페이스 구현체들을 콜하는 방식으로 동적으로 구현해주는 기능, CGLib을 통해)

 

역시나 돌려보는게 이해하기 빠르다

 

예제 네이밍은 조금 이상하긴 하지만.. 설명을 붙이자면

Coffee 인터페이스와 Color 인터페이스가 존재하고

Coffee의 구현체인 Robusta와 Color의 구현체인 Black을 

인트로덕션을 사용해서 CoffeeColor 클래스가 Robusta와 Black을 상속 받은 것처럼 사용해보았다.

 

돌려보기 위해 준비할 클래스

 

0. config 클래스()

//@EnableAspectJAutoProxy 안해주면 에러난다..

package com.meteor.bbbb;

import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.EnableAspectJAutoProxy;

@Configuration
@EnableAspectJAutoProxy
@ComponentScan
public class ConfigTest {

}

1. introduction 될 클래스(TargetClass, ColorCoffee)

package com.meteor.bbbb;

import org.springframework.stereotype.Component;

@Component
public class ColorCoffee {

}

2. introduction 할 내용을 선언한 클래스(CoffeeIntroduction)

package com.meteor.bbbb;

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.DeclareParents;
import org.springframework.stereotype.Component;

@Aspect
@Component
public class CoffeeIntroduction {

	@DeclareParents(value="com.meteor.bbbb.ColorCoffee", defaultImpl=Black.class)
	public Color col;

	@DeclareParents(value="com.meteor.bbbb.ColorCoffee", defaultImpl=Robusta.class)
	public Coffee coffee;
	
	
}

 

3. introduction에 사용되는 인터페이스(Coffee, Color)

package com.meteor.bbbb;

public interface Coffee {
	public void drink();
}

 

package com.meteor.bbbb;

public interface Color {
	public String getColor();

}

4. introduction에 사용되는 인터페이스 구현체 클래스(Robusta, Black)

 

package com.meteor.bbbb;

public class Robusta implements Coffee{
	@Override
	public void drink() {
		System.out.println("robusta drink");
	}

}
package com.meteor.bbbb;

public class Black implements Color{

	@Override
	public String getColor() {
		return "Black";
	}

}

 

마지막으로 돌려보는 테스트 코드

	@Test
	public void contextText2() {
		ApplicationContext context = new AnnotationConfigApplicationContext("com.meteor.bbbb");
		Coffee coffee  = (Coffee) context.getBean(ColorCoffee.class);
		coffee.drink();
		if(coffee instanceof Color) {
			Color col = (Color) coffee;
			System.out.println(col.getColor());
		}
	}

결과는 정상적으로 출력됬다

 

 

 

 

 

 

 

 

디버깅으로 빈 객체를 찍어보니 역시나 CGLIB 으로 프록시 객체를 만든것을 확인할 수 있었다

 

 

 

 

 

 

 

 

 

 

 

그런데.. 이렇게 쓰면 코드 가독성이 떨어질것 같은데..

package com.meteor.bbbb;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@Component
public class ColorCoffeeFix implements Coffee, Color{

	@Autowired
	private Coffee coffee;
	
	@Autowired
	private Color color;
	
	@Override
	public String getColor() {
		return color.getColor();
	}

	@Override
	public void drink() {
		coffee.drink();
	}

}

이렇게 쓰는게 더 좋지 않을까 싶다..

적절한 인트로덕션(introduction) 사용처를 찾아봐야..

댓글()

Spring Event ApplicationEventPublisher

JAVA/Spring|2019. 4. 24. 19:00

Spring에 Event 처리하는 부분이 있길래 의문점이 조금 생겨 코드를 살펴 봤다

물론 동작은 각 설정에 따라 변경될수 있겠지만 기본 설정(가능한 설정을 손 안댄 상태에서)에서 어떻게 동작하는가?

 

"이벤트별 블럭킹 큐에다 넣고 뽑아 가려나?" 그럼 딱히 락처리 할 부분은 없을것 같은데..?

 

코드를 살펴보니 

 

ApplicationEventPublisher에 event들을 발행시, SimpleApplicationEventMulticaster 인경우

TaskExecutor가 지정되어있지 않으면 invokeListener()를 통해 등록된 Listener들을 각각 호출하고 있었다.

 

즉 Listener가 싱글톤인경우 동일 Listener객체에 onApplicationEvent()가 불릴꺼고

싱글톤일 경우 당연히 고려해야 하긴 하겠지만, 여러 스레드가 불릴것은 고려해야 한다.

 

프로토타입의 Publisher 일때는 Listener객체가 싱글톤인 경우 동일 Listener객체가 불리고

 

Listener객체가 프로토타입일 경우 테스트 해보니 invokeListener()시 매번 생성된 Listener객체에 onApplicationEvent() 불리고 있었다.

 

정리

이벤트 발행시에는 붙어있는 이벤트리스너(객체를 재활용하든 매번 만들던)를 직접 부름

 

Publisher : 싱글톤, Listener : 싱글톤

: 여러 스레드가 한 pub 객체를 호출시 동일한 listener의 onApplicationEvent()를 부름

Publisher : 싱글톤, Listener : 프로토타입

: 여러 스레드가 한 pub 객체를 호출시 매번 새로 생성된 listener의 onApplicationEvent()를 부름

Publisher : 프로토타입, Listener : 싱글톤

: 여러 스레드가 여러 pub 객체를 호출시 동일한 listener의 onApplicationEvent()를 부름

Publisher : 프로토타입, Listener : 프로토타입

: 여러 스레드가 여러 pub 객체를 호출시 매번 새로 생성된 listener의 onApplicationEvent()를 부름

 

 

 

 

댓글()