반응형
     1.  SPRING AOP 의 특징 

1)  스프링은 Aspect의 적용 대상(target)이 되는 객체에 대한 Proxy를 만들어 제공.
2) 대상객체(Target)를 사용하는 코드는 대상객체(Target)를 Proxy를 통해서 간접적으로 접근
3) Proxy는 공통기능(Advice)을 실행한 뒤 대상객체(Target)의 실제 메서드를 호출하거나 대상객체(Target)의 실제 메소드가 호출된 뒤 공통기능(Advice)을 실행

AOP에 대해 자세하게 알기 전에 먼저 proxy에 대해 알아보자. 

* 프록시란?
프록시 서버는 기존의 핵심기능이 수행되는 순간 그 기능을 가로채어 앞뒤로 미리 설정된 프록시 기능을 수행해주는 역할을 합니다.

프록시 패턴의 핵심원리는 기존의 기능의 앞, 뒤로 프록시 기능을수행만 하면 된다는 것입니다. 그러므로 기존 기능만 알아서 반복동작한다면 프로그래머는 앞뒤로 덧붙일 기능만 작성하면 됩니다.

다이나믹 프록시는 이런 원리에 입각하여 기존의 메서드를 전부 재작성할 필요 없이 하나의 메서드에 덧붙일 새로운 프록시 기능만 완성시키면 자동으로 모든 메서드에 동일한 프록시 기능을 생성시켜줍니다


기능 10개를 프록시로 작성한다면 늘어난 기능만큼 프록시를 작성해야 한다. 이런걸 막기 위해 자바에서 나온 개념이 바로 다이나믹 프록시이다.


MethodInterceptor 인터페이스: 스프링의 어드바이스를 작성하기 위해 구현해야 할 (스프링에서 사용되는) 다이나믹 프록시 인터페이스입니다.
----> 우리가 MethodInterceptor를 구현하게 되면 반드시 invoke란 메서드를 구현해야 합니다. invoke메서드에 기존의 기능에 앞뒤로 덧붙이기만 하면 다이나믹 프록시가 완성됩니다. 그리고 이것을 포인트컷과 함께 어드바이저에 넘겨주면 끝 (용어를 모르겠다면 밑을 참고!)

     3.  용어 정리

1) 어드바이스(Advice): 특정 조인포인트에서 관점이 취하는 행동(action). "around", "before", "after" 어드바이스같은 여러 가지 타입의 어드바이스가 있다.  -  Joinpoint에서 실행되어야 하는 코드

2) 조인 포인트(Join point): 메서드의 실행이나 예외 처리같은 프로그램이 실행되는 중의 어떤 지점이다. 스프링 AOP에서 조인포인트는 항상 메서드 실행을 나타낸다. - 특정 작업이 실행되는 '시점'을 의미한다.

3) 관점(Aspect): 여러 클레스에 걸친 관심사의 모듈 - Advice와 Pointcut을 합쳐서 하나의 Aspect라고 한다.

4) 포인트컷(Pointcut): 조인포인트를 매칭하는 것(predicate)이다. 어드바이스는 포인트컷 표현식과 연결되고 포인트컷이 매치한 조인포인트에서 실행된다. - Target 클래스와 Advice가 결합(Weaving)될 때 둘 사이의 결합규칙을 정의하는 것이다

5) Weaving : AOP에서 Joinpoint들을 Advice로 감싸는 과정을 Weaving이라고 한다. Weaving 하는 작업을 도와주는 것이 AOP 툴이 하는 역할이다.

6) Target : 실질적인 비지니스 로직을 구현하고 있는 코드

어드바이스(Advice)란 특정 조인포인트에서 관점이 취하는 행동이라고 했다. 그렇다면 advice의 다양한 타입을 알아보자.

1) Before advice: joinpoint전에 수행되는 advice. 하지만 joinpoint를 위한 수행 흐름 처리(execution flow proceeding)를 막기위한 능력은 없다.
2) After returning advice: 메소드가 예외를 던지는것 없이 반환된다면 joinpoint 가 완성된 후에 수행되는 advice.
3) After throwing advice: 메소드가 예외를 던져서 빠져나갈때 수행되는 advice
4) After (finally) advice: join point를 빠져나가는 방법에 상관없이 수행되는 advice.
5) Around advice: 이것은 가장 강력한 종류의 advice이다. Around advice는 메소드 호출 전후에 사용자 정의 행위를 수행할수 있다. 짧게 수행하거나 예외를 던지는 것인지에 대해 책임을 진다.


    4. 포인트컷과 어드바이스

사실 설명만으로는 감이 잘 안올것이다. Spring에서 Aop 기술을 활용한 트랜잭션 예제를 살펴보며 이해하자.
저번 스터디때 트랜잭션은 두가지 방법이 있다고 했다. 그 중, 선언적 방법에는 @Transactional 어노테이션을 활용하는 방법과 <tx:advice>를 이용하는 방법이 있다. 우리 프로젝트(toyproject)에는 어노테이션 방법을 쓸 것이지만 <tx:advice>에 대해 개념은 알아두어야 할 것이다. 지금부터 알아보자!

<tx:annotation-driven />
<aop:config>
     <aop:advisor advice-ref="transactionAdvice" pointcut="bean(*Service)" />
</aop:config>

<tx:advice id="transactionAdvice" transaction-manager="transactionManager">
<tx:attributes>
<tx:method name="exceptionPut" propagation="REQUIRES_NEW" />
<tx:method name="get*" propagation="REQUIRED" read-only="true" />
<tx:method name="*" />
</tx:attributes>
</tx:advice>

<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource" />
</bean>


이 소스에 관해 하나씩 분석 해보자. 먼저 pointcut 에 관한 설명을 해보겠다.

<aop:advisor pointcut="bean(*Service)" advice-ref="transactionAdvice" />

"bean(*Service)"처럼 설정한다면 빈 중에서 Service로 끝나는 모든 빈을 선택하게 됩니다.

포인트컷은 학습테스트나 특별한 기능을 위해서라면 org.springframework.aop.Pointcut 인터페이스를 구현하여 따로 클래스로 만들 수도 있지만 보통은 위의 예제처럼 간편하게 <aop:advisor> 내에 위치시키는 방법이 일반적입니다. 다만 하나 이상의 포인트컷을 입력하고 싶다면 아래 이미지와 같이 구성할 수도 있습니다.



다음으로 우리가 알아볼 것은 바로 어드바이스입니다.


<tx:advice id="transactionAdvice" transaction-manager="transactionManager">
<tx:attributes>
<tx:method name="exceptionPut" propagation="REQUIRES_NEW" />
<tx:method name="get*" propagation="REQUIRED" read-only="true" />
<tx:method name="*" />
</tx:attributes>
</tx:advice>

어드바이스는 포인트컷으로 선택한 빈에 적용될 부가기능을 뜻합니다. AOP는 트랜잭션만을 위한 기술이 아니기 때문에 필요하다면 어드바이스를 통해 포인트컷으로 선별될 빈(또는 클래스, 메서드)의 적용 기술을 자유롭게 변경할 수 있습니다. 물론 여기서 우리가 적용할 부가기능은 바로 트랜잭션입니다.

이런 어드바이스는 org.aopalliance.intercept.MethodInterceptor를 구현하여 만들어집니다. ( MethodInterceptor 인터페이스: 스프링의 어드바이스를 작성하기 위해 구현해야 할 (스프링에서 사용되는) 다이나믹 프록시 인터페이스라고 위에 설명해놓았다. 2번 참고.)

다음은 어드바이저이다.
포인트컷과 어드바이스를 통해 어드바이저를 만들고, 어드바이저는 어드바이스와 포인트컷의 정보를 참조하는 기능을 한다. 다음과 같은 그림을 보면 좀더 이해하기 편하겠다. 앞의  통 소스와 그림과 함께 보면 더욱 이해가 빠를 것이다.
5. 자동프록시생성기

<bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator" />

자동프록시생성기는 기본적으로 org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator 클래스를 뜻합니다. 이 클래스가 빈으로 등록되어 있다면 자동으로 Advisor 인터페이스를 구현한 빈이 컨텍스트에 등록되었는지를 확인해주고 해당 어드바이저들에 정의되있는 포인트컷과 어드바이스를 해석하여 해당 요청이 왔을 때 자동으로 이 요청을 가로채어 프록시를 생성해줍니다. 사용법은 컨텍스트에 해당 빈을 생성해주기만 하는 것으로 끝이 납니다.

단, AOP 기술을 사용한다면  <aop:~>태그만 사용한다면 등록된 어드바이저들은 모두 자동프록시생성기를 통해 해당 포인트컷으로 클래스를 인터셉터하고 어드바이스에 등록된 기능을 수행한다는 보장한다. 


출처: http://truepia.tistory.com/275 [진실세상을 꿈꾸며]

http://egloos.zum.com/springmvc/v/498979

출처: http://devjms.tistory.com/70 [얼렁뚱땅 개발자]

출처  http://wiki.gurubee.net/pages/viewpage.action?pageId=26740833



반응형

'개발공부 > Spring' 카테고리의 다른 글

예외처리(1)  (0) 2020.10.01
Spring에서 Bean을 주입하는 방식  (0) 2020.03.16
SLF4J와 Logback  (1) 2018.06.26
Tiles란, Spring tiles3 적용법  (2) 2018.06.14
반응형
  1.  SLF4J 로깅 처리

    2. 세상에는 여러 Logger들이 존재한다. 무엇을 쓸지는 크게 상관없지만 어플리케이션을 개발할때는 한가지 선택 해야하고, 중요한 것은 의존된 라이브러리가 쓰고 있는 Logger도 잘 확인해야 함. 섞어 쓸 수도 있지만, logging을 제어하려면 하나로 통일 되야 좋다.  여기서 내가 쓰고 싶은 Logger로 통일하고 싶다면 방법은 SLF4J이다.

    SLF4J는 로깅 Facade입니다. 로깅에 대한 추상 레이어를 제공하는것이고 java로 따지면 interface덩어리 라고 보시면 됩니다. artifact이름도 api라고 부릅니다.

    • 사용방법 - pom.xml에 다음과 같은 의존을 추가한다

    <dependency>
      <groupId>org.slf4j</groupId>
       <artifactId>jcl-over-slf4j</artifactId>
      <version>1.7.7</version>
    </dependency>


    실행 코드는 다음과 같다.

    import org.slf4j.Logger;
    import org.slf4j.LoggerFactory;
    public class Sample {
      final Logger logger = LoggerFactory.getLogger(Sample.class);
      public void run() {
      logger.debug("debug");
      logger.info("info");
      }
    }


    하지만 이를 실행하면 다음과 같은 오류가 난다.

    SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".SLF4J: Defaulting to no-operation (NOP) logger implementationSLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.


    구현체가 없기 때문이다. 여기서 구현체란  commons logging, log4j, java util logging, logback 이런 종류의 로깅 구현체를 말한다. 



    1. Logback

    여러 구현체가 존재하지만 나는 Logback을 공부해왔고, 우리 프로젝트에 적용하고 싶다. 그 이유는 다음과 같다. 

    - system.out.println 한줄 남기는데 io 리소스를 너무 많이 먹어서 시스템이 느려짐
    - log4j는 메모리 관리를 따로해서 io쪽에서 메모리를 많이 안먹고 빠르다.
    - log4j를 막 쓰다 보니.. system.out.println 만큼 리소스를 먹게 된다..
    - 이를 보안하기 위해 logback이 개발 됨


    즉, “log4j“에서 제공을 하지 않는 기능 외에 다양한 이점이 있음.

    다양한 이점을 더 알고 싶다면 다음을 참고하자!


    1) logback의 3가지 컴포넌트

    “logback-core“는 말 그대로 핵심 코어 컴포넌트 입니다. “logback-classic“은 “slf4j“에서 사용이 가능하도록 만든 플러그인 컴포넌트 입니다.
    “logback-access“는 사용하는 어플리케이션이 “웹 어플리케이션“일 경우 빛을 바라는 컴포넌트 입니다.” HTTP 요청에 대한 강력한 디버깅 기능을 제공 합니다.”

    2) Graceful recovery from I/O failures

    “Log4j” 같은 경우 “JDBC” , “Socket“등 다양한 “Appender“를 지원 합니다.특히. 대다수의 환경에서는 “File”에 제일 많이 로그를 저장 할 것입니다.
    하지만 만약 “파일 서버가 일시적으로 장애가 발생 할경우” , “파일 서버가 복구 될때까지”“어플리케이션을 중지 시켰다가” 다시 파일 서버가 복구되면, 그때 서버를 재기동 할것 입니다. 하지만 “LOGBack“은 “서버 중지 없이, 이전 시점부터 복구를 graceful “하게 지원을 합니다.

    3) Automatic removal of old log archives

    대부분 환경에서는 “하나의 파일”에 기록하는 것이 아니고, “특정 시간” 또는 “특정 파일 사이즈”로 “Rolling” 해서 “Archiving“을 할 것입니다.
    하지만 “Archiving된 로그 파일“을 계속 유지하지 않고, 일정 기간 지나면 서비스에 부담을 주지 않기 위해서” 파일을 삭제 할것 입니다.
    이럴경우 “Crontab” 또는 다른 삭제 스케줄러를 설정 또는 개발을 할것입니다.“LOGBack“은 “maxHistory“라는 설정 정보를 통해서 주기적으로 “Archive”
    파일을 자동 삭제 합니다.“maxHistory“의 값이 “12“일 경우, “12개월 이후 삭제 하라는” 뜻입니다.

    4) Lilith
    “Lilith“은 “현재 발생하는 로그 이벤트에 대한 상태 정보를 볼수 있도록 지원 하는
    뷰어” 입니다.“log4j“를 지원하는 “chainsaw” 와 비슷한 기능을 합니다. 다만 차이점은 “Lilith” “Large data“를 지원 합니다.

    5) Conditional processing of configuration files

    빌드를 해본 사람이라면 아실듯 합니다. 빌드시 제일 골치가 아픈 것이 “config” 정보 와 “log file path” 입니다.
    이유는 어플리케이션이 구동하는 환경이 “로컬, staging, cbt” 마다 틀리기 때문 입니다. 이런점을 해결 하기 위해서 “Maven Filter” 기능을 사용 하거나, “JVM -D환경변수“를 통해서 각 환경 마다 선택적으로 “log 설정파일“을 선택하도록 구성을 할 것입니다.
    “LOGBack“은 이런 이슈를 좀더 “Graceful“하게 지원을 합니다. “JSTL” 같이 분기 스크립트 (<if>, <then> and <else>)를 제공해서 하나의 파일에서 다양한 빌드 환경을 제공 하도록 지원을 합니다.

    6) Filters

    “Filter” 기능은 “Log4j“에서 지원하는 기능입니다. 주 기능은 “로깅을 남길지 , 말지를”핸드링 할수 있는 기능 입니다.
    좀더 이해를 돕기 위해서 “UseCase“를 설명 드리겠습니다.

    만약 “A“라는 사용자에게 비즈니스적으로 문제점이 발견이 되었습니다.이럴경우는 “logical exception“이기 때문에 원인을 잡기가 쉽지가 않습니다.
    또한 현재 “운영 서버“의 “Log LEVEL“이 “ERROR“일 경우 로그를 확인 할수가 없을것입니다. 더욱이  “운영 서버 logical exception“은 “staging” 환경과 데이터가 틀리기 때문에실제 운영 로그를 확인하지 않고서는 재현을 할수가 없습니다.

    그래서 “운영 서버의 로그 레벨“을 “DEBUG“로 수정합니다. 하지만 로그는 보이지만 전체 사용자가해당이 되기 때문에 로그 데이터를 분석하기가 어렵습니다.
    이럴 경우 “Filter“를 사용해서 “다른 사용자“는 “ERROR” 레벨을 유지하고 ,"A” 사용자만 “DEBUG“로 설정을 하면, 분석하는데 많은 도움을 받을 수 있습니다.

    7) SiftingAppender

    “SiftingAppender“는 “Filter“의 기능과 유사하면서 다른 기능을 제공 합니다 “로그 파일을 특정 주제별로 분류“를 할 수 있도록 합니다.
    예를 들어서 “HTTP Session“별로 로그 파일을 저장한다거나, “사용자별“로 별도의 로그파일을 할 수 있습니다.

    8) Logback-access, i.e. HTTP-access logging with brains, is an integral part of logback

    위에서 언급했듯이 “logback-access“는 “웹 어플리케이션” 사용시 유용한 툴로써 제공 됩니다.특히나 요새는 전통적인 “HTML” 출력이 아닌 “REST 서버“로써의 역할을 많이 합니다. 이럴 경우 “HTTP 디버깅“을 제공 합니다.


    3. Logback 실습 

    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-context</artifactId>
      <version>3.2.4.RELEASE</version>
    </dependency>

    하지만 spring-context는 jarkarta commons logging을 사용하고 있습니다. 실제 이렇게 두면 commons-logging이 의존성에 추가 됩니다. 여기서는 logback을 쓰려고 하니 관련라이브러리는 제거합니다.

    ** 제거하는 방법

         1) pom.xml




    2) Dependency Hierarchy -> commons-logging 우클릭 -> exclude maven artifact


    3) ok


    4) pom.xml에 추가 됬는지 확인





    5)  logback 은 logback-core, logback-classic, logback-access의 3개의 모듈이 있습니다. core는 classic과 access의 공통라이브러리입니다. maven repository를 쓴다면 classic만 추가하면 관련 라이브러리가 추가 됩니다.

    <dependencies>
      <dependency>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-classic</artifactId>
      <version>1.1.2</version>
      </dependency>
    </dependencies>

    이것만 사용하면 기본적인 Log는 사용 가능하다. 

    import ch.qos.logback.classic.LoggerContext;
    import ch.qos.logback.core.util.StatusPrinter;
    import org.slf4j.Logger;
    import org.slf4j.LoggerFactory;

    public class Tutorial {
      private static final Logger logger = LoggerFactory.getLogger(Tutorial.class); 
     // Logger은 꼭 private static이 붙어야 한다. getLogger(클래스명.clss) 적어라.

      public static void main(String[] args) {
      logger.trace("trace");
      logger.debug("debug");
      logger.info("info");
      logger.warn("warn");
      logger.error("error");
      }
    }

    ** Logger들은 Tree Hierarchy 구조로 level을 적용 받을수 있다.




    TRACE > DEBUG > INFO > WARN

    ALL : TRACE와 같음 나중에 확장을 위한것으로 보임.
    TRACE : TRACE, DEBUG, INFO, WARN, ERROR
    DEBUG : DEBUG, INFO, WARN, ERROR
    INFO : INFO, WARN, ERROR
    WARN : WARN, ERROR
    ERROR : ERROR
    OFF : 출력하지 않음

    여기까지 표준이다. 하지만, 좀 더 기능을 확장하고 싶다면 logback.xml을 작성해야 한다.


    Logback.xml

    <?xml version="1.0" encoding="UTF-8"?>
    <configuration> //logback이 구동될때 logback 상태를 확인할 수 있습니다.
      <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
      <layout class="ch.qos.logback.classic.PatternLayout">
      <Pattern>%d{HH:mm} %-5level %logger{36} - %msg%n</Pattern>
      </layout>
      </appender>

      <logger name="example.logback.level.grandparents" level="TRACE"/>
    //example.logback.level.grandparents 이하 모든 Logger들의 level은 TRACE라는 설정입니다.

      <logger name="example.logback.level.grandparents.parents.children" level="INFO"/>
    //example.logback.level.grandparents.parents.children 이하 모든 Logger들의 level은 INFO라는 설정입니다.

      <root level="DEBUG">
                 <appender-ref ref="STDOUT" />
      </root>
    // 모든 대상에 STDOUT Appender를 적용하고 level이 DEBUG이하인것만 처리로 설정됩니다.
    </configuration>



    1. Appender
    Event마다 Log를 기록하는 기능은 Appender가 처리합니다. 그래서 Logger는 어떤 appender에 해당이 되어 처리 되는게 중요합니다. Appender를 설정하더래도 log출력에 해당되지 않으면 작동하지 않습니다.  Appender는 출력될 형식을 직접 가지고 있지 않고, 해당 기능은 Layout과 Encoder에 위임을 합니다.


    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
      <!-- encoders are assigned the type
      ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
      <encoder>
      <pattern>%-4relative [%thread] %-5level %logger{35} - %msg %n</pattern>
      </encoder>
    </appender>

    Appender의 종류 - ConsoleAppender (콘솔로 찍음), FileAppender(파일에 로그남김), RollingFileAppender(rolling 정책이용) ,  EventEvaluator(이벤트 기능으로 로그 남김)

    1) ConsoleAppender 

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
      <!-- encoders are assigned the type
      ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
      <encoder>
      <pattern>%-4relative [%thread] %-5level %logger{35} - %msg %n</pattern>
      </encoder>
    </appender>

    PatternLayoutEncoder는 pattern으로 받은 값을 이용해서 PatternLayout을 생성하고 PatternLayoutEncoder는 log message를 byte[]로 변환하는 기능도 포함합니다. 이로써 Appender는 Layout기능과 Encoder기능을 모두 가지게 됩니다. 이것을 이용해서 OutputStreamAppender는 byte[]를 OuputStream에 write하게 됩니다.

    2) FileAppender

    <!-- Insert the current time formatted as "yyyyMMdd'T'HHmmss" under
      the key "bySecond" into the logger context. This value will be
      available to all subsequent configuration elements. -->
    <timestamp key="bySecond" datePattern="yyyyMMdd'T'HHmmss"/>
    <appender name="FILE" class="ch.qos.logback.core.FileAppender">
           <file>log-${bySecond}.txt</file>
           <append>true</append>
      <!-- encoders are assigned the type
      ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
      <encoder>
      <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>
      </encoder>
    </appender>

    로그가 저장될 file을 선언하고, ConsoleAppender처럼 encoder,pattern을 선언하게 되면, log event를 지정된 file에 저장할 수 있습니다. 이때 파일 포맷중 날짜형식은 java.text.SimpleDateFormat을 따릅니다.

    3) RollingFileAppender
    롤링 정책 적용. 최대 파일 용량 설정가능

    <appender name="ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender">
      <file>mylog.txt</file>
      <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <!-- rollover daily -->
      <fileNamePattern>mylog-%d{yyyy-MM-dd}.%i.txt</fileNamePattern>
      <timeBasedFileNamingAndTriggeringPolicy
      class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
      <!-- or whenever the file size reaches 100MB -->
      <maxFileSize>100MB</maxFileSize>
      </timeBasedFileNamingAndTriggeringPolicy>
      </rollingPolicy>
      <encoder>
      <pattern>%msg%n</pattern>
      </encoder>
    </appender>

    <fileNamePattern> 확장자에 .zip을 선언하면 새로운 file 이 생성될때 이전 파일은 .zip으로 압축을 할수 있습니다.

    4) EventEvaluator
    이벤트 설정. 아래 예는 이메일 설정한 예이다. 이메일 로그 설정 관련 자세한 내용을 보고 싶다면  https://sonegy.wordpress.com/2014/06/03/235/ 출처 참고!

    <appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender">
      <smtpHost>****</smtpHost>
      <smtpPort>25</smtpPort>
      <to>****</to>
      <to>****</to>
      <from>****</from>
      <subject>PRODUCT-PCS: %logger{20} - %m</subject>
      <layout class="ch.qos.logback.classic.PatternLayout">
      <Pattern>%d{HH:mm} %-5level %logger{36} - %msg%n</Pattern>
      </layout>
    </appender>


    ** 공통으로 적용되었던 Layout 패턴에 대해 알아보자!


    • %logger{length}: Logger name의 이름을 축약할 수 있습니다. {length}는 최대 차릿수 입니다.
    • %thread: 현재 Thread name
    • %-5level: log level -5는 출력 고정폭 값
    • %msg: log message %message은 alias
    • %n: new line

    로그 적용시 에러관련 

    출처: http://madeinjeon.tistory.com/18 [Jeon's blog]



반응형

'개발공부 > Spring' 카테고리의 다른 글

예외처리(1)  (0) 2020.10.01
Spring에서 Bean을 주입하는 방식  (0) 2020.03.16
SPRING AOP  (0) 2018.07.02
Tiles란, Spring tiles3 적용법  (2) 2018.06.14

+ Recent posts

티스토리툴바