'Technical Note/SPRING'에 해당되는 글 12건

Technical Note/SPRING

Spring Framework를 통해서 인증(Authentication)과 허가(Authorization)에 관련된 작업을 한다면 여러 방법이 있을수있겠지만

일반적으로 Spring의 서브 프로젝트인 Spring security를 사용하게 된다.
Spring Security는 필터기반으로 동작하므로 Spring MVC 의 구현과 완전히 분리되고 
Spring과의 밀접한 연동으로 메서드 보안등의 여러가지 장점이 있다.
또한 Role기반의 허가를 지원하므로 경로별, 권한별 리소스 제한에 대해서도 많은 기능을 제공한다.
Spring Security를 사용할때 기본적인 Form인증을 사용하는 경우에 대해서 정리해 본다.

1. Spring Framework를 구성한다.

2. Spring security 사이트에서 배포본을 다운 받아 그 안의 jar파일을 라이브러리에 등록한다. (http://www.springsource.org/spring-security#download)

3. 다음의 필터 정의를 web.xml에 추가한다.

<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
  </filter>
  <filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/-</url-pattern>
  </filter-mapping>


이 필터 정의를 추가함으로서 해당 사이트의 모든 요청은 Spring Security를 통해서 처리된다. 

4. 다음의 설정파일을 추가한다. 관리 상 Spring Framework의설정 파일과 분리하는 편이 좋다

<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/security"
    xmlns:beans="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beanshttp://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                        http://www.springframework.org/schema/securityhttp://www.springframework.org/schema/security/spring-security-3.1.xsd">



     <http pattern="/login" security="none"></http>   --> 위 코드는 login 요청에 대해서는 보안을 적용하지 않는다는 것을 의미한다. 
    
     <http auto-config="true" access-denied-page="/login?denied=true">
     <intercept-url pattern="/-*" access="ROLE_USER" />
       <form-login
        login-page="/login"
        authentication-success-handler-ref="loginSuccessHandler"
        authentication-failure-handler-ref="loginFailureHandler"
       />
     <logout logout-success-url="/login" />  

</http>

<beans:bean id="loginSuccessHandler" class="com.preludeb.auth.core.LoginSuccessHandler"></beans:bean>
<beans:bean id="loginFailureHandler" class="com.preludeb.auth.core.LoginFailureHandler"></beans:bean>

<beans:bean id="preludebUserService" class="com.preludeb.auth.core.PreludebUserService"></beans:bean>
<beans:bean id="encoder" class="org.springframework.security.crypto.password.StandardPasswordEncoder"/>

<authentication-manager> 
  <authentication-provider user-service-ref="preludebUserService">
   <password-encoder ref="encoder" />    
  </authentication-provider>
</authentication-manager>
</beans:beans>



좀더 자세히 설명

 <http pattern="/login" security="none"></http>  
 위 코드는 login 요청에 대해서는 보안을 적용하지 않는다는 것을 의미한다. Spring Security를 사용할 때 인증에 관련없이 보여주어야 할 부분(주로 로그인 페이지, 이미지 등의 정적인 리소스 등)은 
<http pattern="/s-ripts/-*" security="none"></http> 같은 형태로 패턴을 추가해 주면 된다. 이 패턴의 설정은 위부터 순서대로 적용되고 패턴매칭이 완료되면 아래의 피턴은 무시되므로 보안 설정을 무시하는 경로는 아래에 나오는 보안 설정 이전에 나와야 한다. 



     <http auto-config="true" access-denied-page="/login?denied=true">
     <intercept-url pattern="/-*" access="ROLE_USER" /> 
       <form-login 
        login-page="/login"
        authentication-success-handler-ref="loginSuccessHandler"
        authentication-failure-handler-ref="loginFailureHandler"
       />
     <logout logout-success-url="/login" />  


위 코드는 실절적으로 웹사이트 경로에 대한 권한 설정을 하는 부분이다.
auto-config = "true" 를 통해서 일반적으로 설정되는 많은 설정 부분이 자동으로 설정된다. 
access-denied-page="/login?denied=true"  부분은 인증을 통과 했지만 해당 요청에 맞는 권한이 없는 경우 보내지는 페이지 경로를 설정한다.  
<form-login 
        login-page="/login"
        authentication-success-handler-ref="loginSuccessHandler"
        authentication-failure-handler-ref="loginFailureHandler"
       /> 는 폼 인증을 사용하겠다는 정의이며, 로그인 페이지는 /login
       인증이 성공할때는 loginSuccessHandler 핸들러로 처리, 
       인증이 실패할때는 loginFailureHandler 핸들러로 처리하겠다는 것을 의미한다.

<logout logout-success-url="/login" /> 은 로그아웃시 리다이렉트 될 페이지를 정의한다.



<beans:bean id="loginSuccessHandler" class="com.preludeb.auth.core.LoginSuccessHandler"></beans:bean> 
는 로그인 성공시 처리할 핸들러 빈의 정의이다. 해당 구현은 잠시 후 살펴본다.


<beans:bean id="loginFailureHandler" class="com.preludeb.auth.core.LoginFailureHandler"></beans:bean>
는 로그인 실패시 처리할 핸들러 빈의 정의이다. 해당 구현은 잠시후 살펴본다.



<beans:bean id="preludebUserService" class="com.preludeb.auth.core.PreludebUserService"></beans:bean>
는 로그인 처리과정에서 UserDetails 객체를 생성하는 UserDetailsService의 빈의 정의이다. 해당 구현은 잠시 후 살펴본다.


<beans:bean id="encoder" class="org.springframework.security.crypto.password.StandardPasswordEncoder"/>
는 Spring Security에서 제공하는 패스워드 인코더의 빈 정의이다. 이 인코더는 random salt를 적용하는 단 방향 해시이며
일반적인 해시와 동일한 형태로 사용하면 된다.
구 버전 spring security 의 경우에는 이 인코더를 지원하지 않으므로 SHA나 MD5 해싱을 이용한다.


Technical Note/SPRING
1. log4j 설치

http://www.apache.org/  - Logging - log4j 1.2 - Download - apache-log4j-1.2.15.zip 
파일을 받아 압축풀어 JAR 파일(log4j-1.2.15.jar)을  프로젝트의 \WEB-INF\lib\ 폴더에 넣습니다

2. log4j 설정 - 콘솔 출력

\WEB-INF\classes 에 log4j.properties 파일을 추가합니다


# Global logging configuration - 전역 리포팅 레벨 설정
log4j.rootLogger=ERROR, stdout
# SqlMap logging configuration... - SqlMap 리포팅 레벨 설정
log4j.logger.com.ibatis=DEBUG
log4j.logger.com.ibatis.common.jdbc.SimpleDataSource=DEBUG
log4j.logger.com.ibatis.common.jdbc.ScriptRunner=DEBUG
log4j.logger.com.ibatis.sqlmap.engine.impl.SqlMapClientDelegate=DEBUG
log4j.logger.java.sql.Connection=DEBUG  
log4j.logger.java.sql.Statement=DEBUG
log4j.logger.java.sql.PreparedStatement=DEBUG
log4j.logger.java.sql.ResultSet=DEBUG

# Console output.. - console 출력 설정
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%5p [%t] -%m%n



log4j.rootLogger=ERROR, stdout
이 내용은 log4j의 리포팅 레벨 기본 설정입니다
ERROR 가 리포팅 레벨이고 stdout은 로그를 남기는 appender 입니다

리포팅 레벨이란 로그를 기록하는 기준?범위?입니다
ERROR 는 에러가 발생했을 경우에만 로그를 남기고
DEBUG 는 항상 로그를 남기게 됩니다. 
이것 외에도 여러가지가 있습니다. PDF 파일 참조  Log4jQuickRef.pdf  

기본설정을 ERROR 로 하고 현재 SqlMap 관련 리포팅 레벨만 DEBUG로 정했기 때문에
평상시에는 SqlMap 관련 로그만 출력됩니다
SqlMap 로그 정보도 에러가 났을 때만 보고싶다면 아래 내용을 모두 주석하시면 됩니다 
log4j.logger.com.ibatis=DEBUG
log4j.logger.com.ibatis.common.jdbc.SimpleDataSource=DEBUG
log4j.logger.com.ibatis.common.jdbc.ScriptRunner=DEBUG 
log4j.logger.com.ibatis.sqlmap.engine.impl.SqlMapClientDelegate=DEBUG
log4j.logger.java.sql.Connection=DEBUG
log4j.logger.java.sql.Statement=DEBUG
log4j.logger.java.sql.PreparedStatement=DEBUG
log4j.logger.java.sql.ResultSet=DEBUG

 


또한 기본설정을 DEBUG로 하게되면 SqlMap말고도 모든 로그가 나오게 됩니다 ( 응 ? )
무슨 내용이 나오는지는 직접 확인 하시길 ../ㅅ/



3. log4j 설정 - 콘솔+파일 출력

log4j.properties 파일을 다음과 같이하면 콘솔과 파일로 출력이 됩니다


# Global logging configuration - 전역 리포팅 레벨 설정
log4j.rootLogger=ERROR, stdout, logfile
# SqlMap logging configuration... - SqlMap 리포팅 레벨 설정
log4j.logger.com.ibatis=DEBUG
log4j.logger.com.ibatis.common.jdbc.SimpleDataSource=DEBUG
log4j.logger.com.ibatis.common.jdbc.ScriptRunner=DEBUG
log4j.logger.com.ibatis.sqlmap.engine.impl.SqlMapClientDelegate=DEBUG
log4j.logger.java.sql.Connection=DEBUG  
log4j.logger.java.sql.Statement=DEBUG
log4j.logger.java.sql.PreparedStatement=DEBUG
log4j.logger.java.sql.ResultSet=DEBUG

# Console output.. - 콘솔 appender 설정
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%5p [%t] -%m%n

# File output - 파일 appender 설정
log4j.appender.logfile=org.apache.log4j.DailyRollingFileAppender
log4j.appender.logfile.DatePattern='.'yyyy-MM-dd
# 로그 파일 path
log4j.appender.logfile.File=c:/log/ibatis.log
# 파일 이어쓰기 여부 ( false 시 서버재시작하면 덮어씀 )
log4j.appender.logfile.Append=true
# 로그 layout 설정
log4j.appender.logfile.layout=org.apache.log4j.PatternLayout
log4j.appender.logfile.layout.ConversionPattern=%d %p [%c] - %m%n


리포팅레벨은 위에서 얘기했고
또 log4j 에서 기본적으로 알아야 할 것은 Appender(출력방식)와 Layout(출력내용) 인데
둘다 살펴 보겠습니다



4. Appender

1) ConsoleAppender : 말그대로 콘솔에 출력하는 방식으로 특별한 설정이 필요없습니다.. 있어도 무시
2) DailyRollingFileAppender : 시간을 주기로 파일을 생성하여 기록하는 방식입니다
DatePattern 으로 시간 단위를 설정 할 수 있습니다
log4j.appender.logfile=org.apache.log4j.DailyRollingFileAppender
#월단위 log4j.appender.logfile.DatePattern='.'yyyy-MM
#주단위 log4j.appender.logfile.DatePattern='.'yyyy-MM-ww
#12시간단위 log4j.appender.logfile.DatePattern='.'yyyy-MM-dd-a
#시간단위 log4j.appender.logfile.DatePattern='.'yyyy-MM-dd-HH
#분단위 log4j.appender.logfile.DatePattern='.'yyyy-MM-dd-HH-mm

  3) RollingFileAppender : 일정 용량만큼 파일에 쓰는 방식입니다

MaxFileSize 로 파일의 최대크기를 정합니다
MaxBackupIndex 으로 파일최대갯수를 지정합니다. 만약 최대갯수까지 차면 처음의 로그파일에 재기록합니다
log4j.appender.logfile=org.apache.log4j.RollingFileAppender
log4j.appender.logfile.MaxFileSize=512KB
log4j.appender.logfile.MaxBackupIndex=3

그 외에도 FileAppender , net.SocketHubAppender .. 등 이 더 있지만 설명은 패스!  Log4jQuickRef.pdf  



5. Layout

간단한 설명만 하겠습니다. 출력 결과는 직접 찍어보시기 바랍니다~

1) PatternLayout : 패턴을 직접 정하는 방식입니다.. 보통 이 방식을 씁니다
ConversionPattern 으로 패턴을 정합니다 ( 자세한 내용은 PDF 파일 참조 Log4jQuickRef.pdf  )
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d %r [%t] %-5p %c %x - %m%n
#log4j.appender.stdout.layout.ConversionPattern=%d %p [%c] - %m%n
#log4j.appender.stdout.layout.ConversionPattern=%5p [%t] -%m%n

2) SimpleLayout : 말그대로 심플하게(?) 보여주는 방식입니다 시간도 안나옵니다.. -_-;
log4j.appender.stdout.layout=org.apache.log4j.SimpleLayout
3) HTMLLayout : HTML테이블 형식으로 만들어줍니다 오오.... 디자인도 맘에 드는군요
log4j.appender.stdout.layout=org.apache.log4j.HTMLLayout
4) TTCCLayout : 심플보다 좀 많이 나옵니다.. 근데 여기서도 시간은 안나오네여 OTL
log4j.appender.stdout.layout=org.apache.log4j.TTCCLayout


Technical Note/SPRING

Spring으로 개발을 한 후 Tomcat Server에서 구동을 하려면 다음과 같은 절차로 진행하시면 됩니다.

1. WebContent 배포
2. Library 배포
3. Class 배포
4. Tomcat 설정

1. WebContent 배포
- Tomcat의 webapps 밑에 project 폴더(예:myprj)를 생성하여 해당 파일들을 배포합니다.
예) tomcat–webapps–myprj–
|-index.jsp
|-css
|-images
|-js
|-WEB-INF

2. Library 배포
WEB-INF/lib 폴더에 *.jar 파일을 배포합니다.
* mysql 사용하실 경우에는 connector도 이곳에 배포합니다.(mysql-connector-java-5.1.15-bin.jar)

3. Class 배포
class 파일들은 WEB-INF/classes에 배포합니다.

4. Tomcat 설정
tomcat root/conf/server.xml에 아래 내용을 수정합니다.

<Host appBase=”webapps” autoDeploy=”true” deployOnStartup=”true” deployXML=”true” name=”localhost” unpackWARs=”true” xmlNamespaceAware=”false” xmlValidation=”false”><Context docBase=”프로젝트명(myprj)” path=”" reloadable=”true” source=”org.eclipse.jst.jee.server:프로젝트명(myprj)“/></Host>

 

 

*한글 설정
WEB-INF/web.xml에 아래 내용을 추가해 주시면 한글을 정상적으로 사용가능합니다.

<filter>
                <filter-name>encoding</filter-name>
                <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
                <init-param>
                        <param-name>encoding</param-name>
                        <param-value>EUC-KR</param-value>
                </init-param>
        </filter>


Technical Note/SPRING

poolPreparedStatement 속성 정의

DBCP사용시 설정 정보중 <poolPreparedStatement> 란 속성이 있다.
이 속성은 PreparedStatement의 풀 사용 여부를 의미하며, default 값은 "false"이다. 



Prepared Statement Pooling 이란?

statement preparation은 RDBMS의 실행에 있어 비용이 많이 드는 작업이며 복잡한 SQL문일수록 더욱 높은 비용이 소모된다. 
각각의 statement preparation은 문법 오류 검증(syntactical correctness), 컬럼 참조(column references)의 유효성 검증, 최적화된 접근경로와 execution plan의 식별등을 수행한다.

Preparation을 위해서 statement을 매번 RDBMS에서 얻어와야 하는데, 자주 실행되는 Statement를 사전에 Prepare하여 Application이 호출할 수 있는 Common Place(pool)에 저장해 놓는것이 보다 효과적인 방법일 것이다.
이렇게 pool에서 Prepare된 statement을 갖고 오는 방법을 Prepared Statement Pooling 이라고 한다. 

Prepared Statement Pool 생성 매커니즘

  • BasicDataSource 타입의 dataSource 객체에서 Connection 객체를 가져올때 아래의 그림과 같이 두가지의 단계가 수행된다.
    1. Connection Pool이 있다면 Pool에서 Connection을 얻어온다.
    2. PrepareStatement Pool이 생성된다. 이때 Pool 의 크기는 maxOpenPreparedStatements 값에 따라 결정된다. 



  • 얻어온 Connection 객체에서 PrepareStatement 를 수행할 때, PrepareStatement Pool에서 Statement 객체를 얻어온다. 

Prepared Statement Pooling 을 쓰는 이유

다음은 Prepared Statement Pooling을 사용함으로써 얻을 수 있는 이득이다.

  • RDBMS가 Statement를 Prepare하는 시간을 줄일 수 있기 때문에 Application이 RDBMS로부터 데이터를 로딩하는 성능이 향상된다.
  • Statement cashing이 자동으로 수행되므로, Application개발자는 Statement pooling에 관한 지식이 없이도 JDBC Application을 개발할 수 있다.
  • Statement pooling과 Connection pooling을 함께 사용하면 Connection pooling을 단독으로 사용하는 것보다 큰 성능향상을 가져온다.



Prepared Statement Pooling 과 Connection Pool을 함께 사용할 때의 장점

Connection pool을 사용하지 하지 않는 경우 Application이 disconnect 되었을 때 Prepared statement pool 이 사라진다. 
그러나 Connection pool과 Prepared statement pool을 동시에 사용하는 경우, Application이 disconnect 되어 사용하던 Connection이 pool로 return될때, Prepared statement pool도 함께 return 된다. 
그 후, Application이 Connect 했을 때 Statement Preparation을 다시 수행할 필요 없이, Connection에 남아 있는 Prepared statement pool 를 재 사용하게 된다. 

poolPreparedStatement 속성 사용시 주의 사항

  • poolPreparedStatement 속성을 "true"로 설정하였을 경우, 반드시 <maxOpenPreparedStatements> 속성을 함께 사용해 커넥션 당 풀링할 preparedstatement의 적절한 개수를 설정해줘야 한다.
    이 값이 적정하지 않을 경우, 런타임 시 Out of Memory 등의 에러가 발생할 수 있다.

    maxOpenPreparedStatements : 풀의 최대 PreparedStatement 의 개수이며 default는 "unlimited"이다.



poolPreparedStatement 가 성능에 미치는 영향

만약 사용하는 SQL 개수에 비하여 preparedstatement의 Pool의 크기가 작다면, statement를 얻기 위한 비용으로 인해 메모리 사용율이 높아진다. 
반면, Pool의 크기가 크다면 "SQL 길이(statement 객체 크기) * pool 갯수 * connection 갯수" 만큼의 메모리가 쓰여지므로, Out of memory가 발생할 수 있다.
그러므로 적정한 Pool의 크기를 정의해야 성능상 효과를 볼 수 있을 것이다.

Technical Note/SPRING

1. weaving의 개념 
cross-cutting concern을 구현한 코드를 핵심 로직안에 삽입하는 것 


2. 세가지 Weaving 방법

  • 컴파일시 Weaving : AspectJ에서 사용하는 방식, AOP가 적용된 class파일이 생성
  • 클래스 로딩 시에 Weaving : AOP라이브러리중 JVM이 클래스를 로딩할 때 클래스 정보를 변경할수있는 Agent를 제공
  • 런타임 시에 Weaving : 런타임시에 AOP를 적용할 때는 소스코드나 클래스 정보 자체를 변경하지 않음
    프록시를 이용하여 AOP를 적용, 프록시 기반에서는 메서드가 호출할때에만 Advice를 적용할수있기 때문에 필드값 변경과 같은 Jointpoint에 대해서는 적용할수 없는 한계가 있음




3. Spring 에서의 AOP
스프링은 자체적으로 프록시 기반의 AOP를 지원하고 있다. 따라서, 스프링 AOP는 메소드 호출 Jointpoint만을 지원한다. 필드 값 변경과같은 Jointpoint를 사용하고 싶다면 AspectJ와 같이 풍부한 기능을 지원하는 AOP도구를 사용해야만 한다.

Spring에서 프록시 객체를 생성할떄 대상 객체가 인터페이스를 구현하고 있어야 한다. 
왜냐하면 Spring은 자바 리플랙션 api가 제공하는 java.lang.reflect.Proxy를 이용하여 프록시 객체를 생성하기 때문이다.
대상 객체가 인터페이스를 구현하고 잇지 않다면, spring은 CGLIB를 이용하여 클래스에 대한 프록시 객체를 생성해야 한다.




4. Spring에서의 AOP 실습

실습 과제 : method 단위의 수행시간을 추출 
아래의 3가지 방식으로 weaving 을 구현해 보았다.
1. Spring API를 이용 
2. AspectJ 5에서 정의한 @Aspect 어노테이션을 이용
3. CGLIB 를 이용




5. 구간별 수행시간 추출 기능 요구사항 정리
1. method 단위 수행시간 계산
2. 내부 class 분석기능

  • preparedstatement등의 Jdbc api class에 접근하여 SQL문 추출 기능
  • HttpClient의 수행시간 계산, URL 추출 기능
  • 기타... 고민해야 할 부분

3. Multi thread 로 수행함으로써 동시에 여러 서비스 구간분석




6. 결과

  • Bean으로 만들어진 Class안에 모든 Method의 수행시간은 추출가능




7. 미해결 문제

  • Bean으로 만들어진 Class가 아닌 경우는 구간분석 툴에서 무시됨
  • preparedstatement등 내부에서 사용하는 Class가 설정파일에 정의된 Advice, Pointcut 정보를 가져오지 못함
  • 위의 항목이 해결되면 Multi Thread 방식으로 확장 계획




참고1 - 용어 정리

  • 공통 관심 사항 : cross-cutting concern
  • 핵심 관심 사항 : core concern
  • Aspect : 여러 객체에 공통으로 적용되는 공통 관심 사항을 Aspect라 함.
  • Advice : 언제 공통 관심 기능을 핵심 로직에 적용할지를 정의하고 있음. 예를 들어, '메서드를 호출하기 전에'(언제) 에 '트랜잭션을 시작한다'(공통기능) 기능을 적용한다는것을 정의
  • Joinpoint : Advice를 적용 가능한 지점. 메소드 호출, 필드값 변경 등 Joinpoint에 해당됨
  • Pointcut : Joinpoint의 부분집합으로써 실제로 advice가 적용되는 Joinpoint를 나타냄. 스프링에서는 정규 표현식이나 AspectJ의 문법을 이용하여 Pointcut을 정의




참고2 - AspectJ의 Pointcut 표현식

execution 명시자 (Advice를 적용할 메소드(핵심관심사항을 구현한 메소드)를 지정)

execution([접근자제어패턴] , 리턴타입패턴 [패키지패턴]메서드이름패턴(파라메터패턴)) [ ] 안의 패턴은 생략 가능

  • execution(public void set*(..))
    public에 리턴값이 없으며, 패키지명은 없고, 메서드는 set으로 시작하며 인자값은 0개 이상인 메서드 호출
  • execution(* com.peoplesgroove..())
    리턴타입에 상관없이 com.peoplesgroove패키지의 인자값이 없는 모든 메서드 호출
  • execution(* com.peoplesgroove...(..))
    리턴타입에 상관없이 com.peoplesgroove 패키지 및 하위 패키지에 있는, 인자값이 0개 이상인 메서드 호출
  • execution(Integer com.peoplesgroove.WriteArticleService.write(..))
    리턴 타입이 Integer인 WriteArticleServlce 의 인자값이 0개 이상인 write() 호출
  • execution(* get*(*))
    메서드 이름이 get으로 시작하는 인자값이 1개인 메서드 호출
  • execution(* get*(,))
    메서드 이름이 get으로 시작하는 인자값이 2개인 메서드 호출
  • execution(* get*(Integer, ..))
    메서드 이름이 get으로 시작하고 첫번째 인자값의 데이터타입이 Integer이며, 1개 이상의 인자값을 갖는 메서드 호출
  • execution(* com..*(..)) && @annotation(@annotation)
    @annotation이 있는 모든 메소드 호출
  • execution(* *(..,@annotation (*), ..))
    @annotation을 파라메터로 갖고 있는 모든 메소드 호출|
within 명시자 (특정 패키지나 클래스, 인터페이스 내의 메소드 지정)
  • within(test.bean.BoardService)
    --> BoardService 인터페이스의 모든 메소드
  • within(test.bean.*)
    --> test.bean 패키지 내의 모든 메소드
  • within(test.bean..*)
    --> test.bean 패키지 및 그 하위 패키지 내의 모든 메소드
bean 명시자 (빈 설정파일에 등록된 빈의 이름을 이용하여 메소드 지정)
  • bean(myBean)
    --> 이름이 myBean 인 빈의 메소드
  • bean(*Service)
    --> 이름이 Service로 끝나는 모든 빈의 메소드

레퍼런스


1 2 3
블로그 이미지

zzikjh