SpringBoot 사용자 정의 FailureAnalyzer 프로 세 스 분석

이 글 은 주로 SpringBoot 사용자 정의 Failure Analyzer 를 소개 하 였 으 며,예시 코드 를 통 해 매우 상세 하 게 소개 되 어 있 으 며,여러분 의 학습 이나 업무 에 대해 어느 정도 참고 학습 가치 가 있 으 므 로 필요 한 분 들 은 참고 하 시기 바 랍 니 다.
홈 페이지 설명
1.1 자신의 Failure Analyzer 만 들 기
Failure Analyzer 는 시작 할 때 exception 을 차단 하고 human-readable 메시지 로 변환 하 는 좋 은 방법 으로 고장 분석 에 포함 된다.Spring Boot 는 application context 와 관련 된 exceptions,JSR-303 검증 등에 이러한 분석 기 를 제공 합 니 다.실제로 자신 을 만 들 기 쉽다.
AbstractFailure Analyzer 는 Failure Analyzer 의 편리 한 확장 입 니 다.exception 에 지정 한 exception 형식 이 있 는 지 확인 합 니 다.그 중에서 확장 할 수 있 습 니 다.그러면 implementation 은 실제 존재 할 때 만 exception 을 처리 할 수 있 습 니 다.만약 어떤 이유 로 exception 을 처리 할 수 없다 면,return null 은 다른 implementation 에 exception 을 처리 할 기 회 를 줍 니 다.
FailureAnalyzer __mplement 은 META-INF/spring.factories 에 등 록 됩 니 다.다음 레지스터 ProjectConstraint ViolationFailure Analyzer:

org.springframework.boot.diagnostics.FailureAnalyzer=\
com.example.ProjectConstraintViolationFailureAnalyzer

1.2 고장 제거 auto-configuration
Spring Boot auto-configuration 은 최선 을 다 하지만 때로는 일이 실패 할 수도 있 고 원인 을 말 하기 도 어렵다.
Spring Boot Application Context 에 매우 유용 한 Condition EvaluationReport 가 있 습 니 다.DEBUG logging 출력 을 사용 하면 볼 수 있 습 니 다.spring-boot-actuator 를 사용 하면 터미널 이 하나 더 있 습 니 다.JSON 으로 보고 서 를 보 여 줍 니 다.애플 리 케 이 션 을 디 버 깅 하고 Spring Boot 가 실 행 될 때 어떤 features(그리고 없 는 것)를 추 가 했 는 지 확인 합 니 다.
source code 와 자바 doc 를 보면 더 많은 질문 에 대답 할 수 있 습 니 다.일부 경험 법칙:

*AutoConfiguration 이라는 classes 를 찾 아 원본 을 읽 습 니 다.특히@Conditional*설명 은 사용 하 는 features 와 언제 사용 하 는 지 찾 습 니 다.--debug 를 명령 라인 이나 System property-Debug 에 추가 하여 console 에 log 를 추가 하여 프로그램 에서 내 린 모든 auto-configuration 결정 을 내 립 니 다.running Actuator 응용 프로그램 에서 autoconfig 터미널('/autoconfig'또는 JMX 등가 항목)을 보고 같은 정 보 를 얻 습 니 다

@ConfigurationProperties(예:ServerProperties)의 classes 를 찾 아 사용 가능 한 외부 configuration 옵션 을 읽 습 니 다.@ConfigurationProperties 는 name 속성 이 있 습 니 다.외부 properties 의 접두사 이기 때문에 ServerProperties 는 prefix="server"가 있 습 니 다.configuration properties 는 server.port,server.address 등 입 니 다.running Actuator 응용 프로그램 에서 configprops 터미널 을 봅 니 다

Relaxed Property Resolver 를 사용 하여 Environment 에서 configuration 값 을 명확 하 게 추출 하 는 것 을 찾 습 니 다.그것 은 보통 접두사 와 함께 사용한다

Environment 에 직접 연 결 된@Value 주석 을 찾 습 니 다.이것 은 Relaxed Property Resolver 방법 보다 유연 하지 않 지만 가 벼 운 binding,특히 OS 환경 변 수 를 허용 합 니 다(따라서 CAPITALSAND_UNDERSCORES 는 period.separated 의 동의어 이다

@ConditionalOnExpression 주석 을 찾 아 SpEL 표현 식 에 응답 하여 features 를 열 고 닫 습 니 다.보통 Environment 에서 분 석 된 자리 표시 자 를 사용 하여 평 가 를 합 니 다

1.3 시작 하기 전에 Environment 또는 Application Context 사용자 정의
SpringApplication 은 ApplicationListeners 와 ApplicationContextInitializers 를 가지 고 있 으 며,사용자 정의 컨 텍스트 나 환경 에 사용 할 수 있 습 니 다.Spring Boot 는 META-INF/spring.factories 내부 에서 사용 할 수 있 도록 사용자 정의 항목 을 많이 불 러 왔 습 니 다.다른 방법 을 등록 하 는 방법 은 한 가지 가 아니다.

통 과 는실행 하기 전에 SpringApplication 의 addListeners 와 addInitializers 방법 을 호출 하여 프로 그래 밍 방식 으로 모든 application 을 사용 합 니 다

context.initializer.classes 나 context.listener.classes 를 설정 하여 모든 애플 리 케 이 션 을 설명 합 니 다

META-INF/spring.factories 추가 및 포장appar 는 모두 library 의 jar 파일 로 모든 applications 를 설명 합 니 다

SpringApplication 은 listeners 에 특수 한 applicationEvents(심지어 context 를 만 들 기 전의 일부)를 보 낸 다음 에 applicationContext 에서 발표 한 이벤트 에 listeners 를 등록 합 니 다.
Environment PostProcessor 를 사용 하여 application context 를 새로 고치 기 전에 Environment 를 사용자 정의 할 수 있 습 니 다.모든 implementation 은 META-INF/spring.factories 에 등록 해 야 합 니 다.

org.springframework.boot.env.EnvironmentPostProcessor=com.example.YourEnvironmentPostProcessor

implementation 은 임의의 files 를 불 러 와 Environment 에 추가 할 수 있 습 니 다.예 를 들 어,이 example 는 classpath 에서 YAML configuration 파일 을 불 러 옵 니 다.

public class EnvironmentPostProcessorExample implements EnvironmentPostProcessor {

  private final YamlPropertySourceLoader loader = new YamlPropertySourceLoader();

  @Override
  public void postProcessEnvironment(ConfigurableEnvironment environment,
      SpringApplication application) {
    Resource path = new ClassPathResource("com/example/myapp/config.yml");
    PropertySource<?> propertySource = loadYaml(path);
    environment.getPropertySources().addLast(propertySource);
  }

  private PropertySource<?> loadYaml(Resource path) {
    if (!path.exists()) {
      throw new IllegalArgumentException("Resource " + path + " does not exist");
    }
    try {
      return this.loader.load("custom-resource", path, null);
    }
    catch (IOException ex) {
      throw new IllegalStateException(
          "Failed to load yaml configuration from " + path, ex);
    }
  }

}

Environment 는 Spring Boot 기본 으로 불 러 오 는 모든 상용 property 원본 을 준비 하 였 습 니 다.따라서 환경 에서 파일 의 위 치 를 가 져 올 수 있다.이 example 는 목록 끝 에 custom-resource property 원본 을 추가 하여 다른 일반적인 위치 에서 정의 하 는 key 우선 순 위 를 지정 합 니 다.사용자 정의 implementation 은 분명히 다른 order 를 정의 할 수 있 습 니 다.
@SpringBootApplication 에서@PropertySource 를 사용 하 는 것 이 편리 하고 Environment 에 사용자 정의 자원 을 불 러 오기 쉬 운 것 같 지만,Spring Boot 가 applicationContext 가 새로 고침 되 기 전에 Environment 를 준비 하 는 것 을 추천 하지 않 습 니 다.@PropertySource 를 통 해 정 의 된 모든 key 는 auto-configuration 에 영향 을 주지 않 고 너무 늦게 불 러 옵 니 다.
코드 예제
2.1 지정 이상 분석
SpringBoot 내부 에서 제공 하 는 작 동 이상 분석 은 모두 구체 적 인 이상 유형 을 지정 하여 이 루어 진 것 입 니 다.가장 흔히 볼 수 있 는 오 류 는 포트 번호 가 점용 되 는 것 입 니 다(PortInUseException).SpringBoot 내부 에서 이 이상 한 작 동 분석 을 제공 하지만 우 리 는 이 이상 분석 을 대체 할 수 있 습 니 다.PortInUseException 이상 의 AbstractFailure Analyzer 를 만 들 고 클래스 를 SpringBoot 에 등록 하면 다음 과 같은 사용자 정의 가 가능 합 니 다.

/**
 * @author WGR
 * @create 2019/11/24 -- 23:00
 */
public class PortInUseFailureAnalyzer extends AbstractFailureAnalyzer<PortInUseException> {
  /**
   * logger instance
   */
  static Logger logger = LoggerFactory.getLogger(PortInUseFailureAnalyzer.class);

  @Override
  protected FailureAnalysis analyze(Throwable rootFailure, PortInUseException cause) {
    logger.error("     。", cause);
    return new FailureAnalysis("   ：" + cause.getPort() + "   ", "PortInUseException", rootFailure);
  }
}

등록 시작 이상 분석
위 에서 저 희 는 지정 한 이상 시작 분석 만 작 성 했 습 니 다.다음 에 효력 을 발생 시 켜 야 합 니 다.이 효력 발생 방식 은 사용자 정의 SpringBoot Starter AutoConfiguration 과 유사 합 니 다.저 희 는 META-INF/spring.factories 파일 에서 정 의 를 내 려 야 합 니 다.다음 과 같 습 니 다.

org.springframework.boot.diagnostics.FailureAnalyzer=\
 com.topcheer.activiti.analyzer.PortInUseFailureAnalyzer

그럼 우 리 는 왜 이런 방식 으로 정 의 를 내 려 야 합 니까?
프로젝트 시작 에 발생 하 는 이상 순 서 는 확인 되 지 않 습 니 다.Spring IOC 가 초기 화 되 기 전에 이상 이 발생 했 을 가능성 이 높 습 니 다.@Component 주해 형식 으로 적용 할 수 없 기 때문에 SpringBoot 는 spring.factories 설정 파일 을 통 해 정 의 를 제공 합 니 다.
테스트:8080 포트 2 개 시작

이상 분석 상속 관계 시작
사용자 정의 실행 이상 은 일반적으로 Runtime Exception 에서 계승 합 니 다.Runtime Exception 의 이상 시작 분석 인 스 턴 스 를 정의 하면 어떤 효과 가 있 습 니까?

public class ProjectBootUnifiedFailureAnalyzer extends AbstractFailureAnalyzer<RuntimeException> {
  /**
   * logger instance
   */
  static Logger logger = LoggerFactory.getLogger(ProjectBootUnifiedFailureAnalyzer.class);

  @Override
  protected FailureAnalysis analyze(Throwable rootFailure, RuntimeException cause) {
    logger.error("       ", cause);
    return new FailureAnalysis(cause.getMessage(), "error", rootFailure);
  }
}

이 클래스 도 spring.factories 파일 에 함께 등록 합 니 다.다음 과 같 습 니 다.

org.springframework.boot.diagnostics.FailureAnalyzer=\
com.topcheer.activiti.analyze.PortInUseFailureAnalyzer,\
com.topcheer.activiti.analyze.ProjectBootUnifiedFailureAnalyzer

프로젝트 를 실행 하고 포트 번호 가 이상 하 게 점용 되 었 음 을 테스트 하면 ProjectBootUnified Failure Analyzer 의 analyzer 방법 을 실행 하지 않 고 PortInUseFailure Analyzer 클래스 의 방법 을 계속 실행 한 것 을 발견 할 수 있 습 니 다.
그러면 우 리 는 PortInUseFailureAnalyzer 라 는 시작 분석 을 spring.factories 파일 에서 잠시 삭제 하고 프로젝트 를 실행 합 니 다.이 때 는 ProjectBootUnified FailureAnalyzer 류 의 분석 방법 을 실행 하 는 것 을 발견 할 수 있 습 니 다.
총결산
이 장 에서 우 리 는 SpringBoot 가 제공 하 는 작 동 이상 분석 인터페이스 와 기본 추상 적 인 실현 류 의 운영 원 리 를 알 게 되 었 고 이상 분석 을 시작 하면 범 형 이상 류 의 상하 상속 관 계 를 분석 하고 이상 서브 류 의 작 동 분석 은 이상 부모 류 의 작 동 분석 을 덮어 버 릴 것 이다.모든 이상 한 시작 분석 을 포함 하고 싶다 면 Exception 을 AbstractFailure Analyzer 의 일반적인 매개 변수 로 사용 해 보 세 요.
이상 이 바로 본 고의 모든 내용 입 니 다.여러분 의 학습 에 도움 이 되 고 저 희 를 많이 응원 해 주 셨 으 면 좋 겠 습 니 다.