@CreatedDate, @LastModifiedDate의 경우는 JPA가 생성일시, 수정일시 정보를 알 수 있기 때문에 

아래의 어노테이션만 달아주면 정상적으로 생성일시, 수정일시 정보가 DB에 저장됐다.

// 해당 엔티티에 적용
@EntityListeners(AuditingEntityListener.class)

// Auditing을 활성화하기 위해 PersistenceConfig에 적용
@EnableJpaAuditing

 

하지만 @CreatedBy, @LastModifiedBy는 누가 해당 엔티티를 생성, 수정했는지(엔티티를 생성, 수정하는 api를 호출했는지) JPA가 알 수 없기 때문에 추가 작업이 필요하다.

기존의 날짜 자동 생성을 위해 @EnableJpaAuditing을 적용해둔 클래스에 AuditorAware 클래스를 활용해서 유저 정보를 꺼내는 로직을 작성해야 한다.

 

// 방법 1
@Configuration
@EnableJpaAuditing
public class PersistenceConfig {
	@Bean
	public AuditorAware<Long> auditorProvider() {
		return () -> Optional.of(Long.parseLong(SecurityContextHolder.getContext().getAuthentication().getName()));
	}
}
// 방법 2
@Configuration
@EnableJpaAuditing
public class PersistenceConfig implements AuditorAware<Long> {
	@Override
	public Optional<Long> getCurrentAuditor() {
		return Optional.of(Long.parseLong(SecurityContextHolder.getContext().getAuthentication().getName()));
	}
}

 

첫 번째의 경우는 Config에서 직접 메서드를 빈으로 등록해서 실행시키는 방법으로, 

AuditorAware를 반환타입으로 선언해서 람다식으로 AuditorAware의 구현체 형태를 리턴하는 방식이다.

AuditorAware의 추상 메서드가 하나밖에 없기 때문에 람다식으로 간단히 표현이 가능하다.

 

두 번째의 경우는 AuditorAware를 implements로 구현하는 클래스로 생성하는 것이다.

이 경우에는 스프링이 자동으로 해당 메서드를 빈으로 등록해주기 때문에 @Bean 어노테이션 없이 AuditorAware의 추상 메서드를 오버라이딩 해주면 된다.

 

AuditorAware는 optional로 감싸진 데이터를 반환하도록 되어있기 때문에, Optional 클래스의 of 메서드를 사용해서 return 해야 한다.