출처 : http://blog.naver.com/PostView.nhn?blogId=idtong&logNo=130035405925

[Mail] Sendmail 오류 메시지

Mail 2012/02/16 12:40

@SuppressWarnings("rawtypes")

출처 : http://agagomty.blogspot.kr/2012/12/suppresswarningsrawtypes.html

EHCache를 이용한 기본적인 캐시 구현 방법 및 분산 캐시 구현 방법을 살펴본다.

EHCache의 주요 특징 및 기본 사용법

게시판이나 블로그 등 웹 기반의 어플리케이션은 최근에 사용된 데이터가 또 다시 사용되는 경향을 갖고 있다. 80:20 법칙에 따라 20%의 데이터가 전체 조회 건수의 80%를 차지할 경우 캐시를 사용함으로써 성능을 대폭적으로 향상시킬 수 있을 것이다.

본 글에서는 캐시 엔진 중의 하나인 EHCache의 사용방법을 살펴보고, Gaia 시스템에서 EHCache를 어떻게 사용했는 지 살펴보도록 하겠다.

EHCache의 주요 특징

EHCache의 주요 특징은 다음과 같다.

• 경량의 빠른 캐시 엔진
• 확장(scable) - 메모리 & 디스크 저장 지원, 멀티 CPU의 동시 접근에 튜닝
• 분산 지원 - 동기/비동기 복사, 피어(peer) 자동 발견
• 높은 품질 - Hibernate, Confluence, Spring 등에서 사용되고 있으며, Gaia 컴포넌트에서도 EHCache를 사용하여 캐시를 구현하였다.

기본 사용법

EHCache를 사용하기 위해서는 다음과 같은 작업이 필요하다.

1. EHCache 설치
2. 캐시 설정 파일 작성
3. CacheManager 생성
4. CacheManager로부터 구한 Cache를 이용한 CRUD 작업 수행
5. CacheManager의 종료

EHCache 설치

EHCache 배포판은 http://ehcache.sourceforge.net/ 사이트에 다운로드 받을 수 있다. 배포판의 압축을 푼 뒤, ehcache-1.2.x.jar 파일이 생성되는 데, 이 파일을 클래스패스에 추가해준다. 또한, EHCache는 자카르타의 commons-logging API를 사용하므로, commons-logging과 관련된 jar 파일을 클래스패스에 추가해주어야 한다.

ehcache.xml 파일

EHCache는 기본적으로 클래스패스에 존재하는 ehcache.xml 파일로부터 설정 파일을 로딩한다. 가장 간단한 ehcache.xml 파일은 다음과 같이 작성할 수 있다.

위 코드에서 <defaultCache> 태그는 반드시 존재해야 하는 태그로서, 코드에서 캐시를 직접 생성할 때 사용되는 캐시의 기본 설정값을 저장한다. <cache> 태그는 하나의 캐시를 지정할 때 사용된다. name 속성은 캐시의 이름을 지정하며, 코드에서는 이 캐시의 이름을 사용하여 사용할 Cache 인스턴스를 구한다.

설정 파일에 대한 자세한 내용은 뒤에서 살펴보기로 하자.

CacheManager 생성

ehcache.xml 파일을 작성했다면 그 다음으로 할 작업은 net.sf.ehcache.CacheManager 객체를 생성하는 것이다. CacheManager 객체는 다음의 두 가지 방법 중 한가지 방식을 사용하여 생성할 수 있다.

• CacheManager.create() : 싱글톤 인스턴스 사용
• new CacheManager() : 새로운 CacheManager 인스턴스 생성

CacheManager.create() 메소드는 싱글톤 인스턴스를 생성하기 때문에 최초에 한번 호출될 때에만 CacheManager의 초기화 작업이 수행되며, 이후에는 동일한 CacheManager 인스턴스를 리턴하게 된다. 아래는 CacheManager.create() 메소드의 사용 예이다.

싱글톤 인스턴스가 아닌 직접 CacheManager 객체를 조작하려면 다음과 같이 new를 사용하여 CacheManager 인스턴스를 생성해주면 된다.

두 방식 모두 클래스패스에 위치한 ehcache.xml 파일로부터 캐시 설정 정보를 로딩한다.

만약 클래스패스에 위치한 ehcache.xml 파일이 아닌 다른 설정 파일을 사용하고 싶다면 다음과 같이 URL, InputStream, 또는 String(경로) 객체를 사용하여 설정 파일의 위치를 지정할 수 있다.

Cache에 CRUD 수행

CacheManager 인스턴스를 생성한 다음에는 CacheManager 인스턴스로부터 Cache 인스턴스를 구하고, Cache 인스턴스를 사용하여 객체에 대한 캐시 작업을 수행할 수 있게 된다. 

Cache 구하기
net.sf.ehcache.Cache 인스턴스는 CacheManager.getCache() 메소드를 사용하여 구할 수 있다.

CacheManager.getCache() 메소드에 전달되는 파라미터는 ehcache.xml 설정 파일에서 <cache> 태그의 name 속성에 명시한 캐시의 이름을 의미한다. 지정한 이름의 Cache 인스턴스가 존재하지 않을 경우 CacheManager.getCache() 메소드는 null을 리턴한다.

Create/Update 작업 수행
Cache 인스턴스를 구한 다음에는 Cache.put() 메소드를 사용하여 캐시에 객체를 저장할 수 있다. 아래 코드는 Cache.put() 메소드의 사용예이다.

Cache.put() 메소드는 net.sf.ehcache.Element 객체를 전달받는다. Element 클래스는 캐시에 저장될 원소를 나타내며, 키와 값을 사용하여 원소를 표현한다. Element 객체를 생성할 때 첫번째 파라미터는 원소의 키를 의미하며, 두번째 파라미터는 원소의 값을 의미한다.

EHCache는 캐시에 저장될 각각의 객체들을 키를 사용하여 구분하기 때문에, Element 객체를 생성할 때 (의미상) 서로 다른 객체는 서로 다른 키를 사용해야 한다.

Map과 마찬가지로 EHCache가 제공하는 Cache는 삽입을 하거나 기존의 값을 수정할 때 모두 Cache.put() 메소드를 사용한다. 기존에 캐시에 저장된 객체를 수정하길 원한다면 다음과 같이 동일한 키를 사용하는 Element 객체를 Cache.put() 메소드에 전달해주면 된다.

Read 작업 수행
Cache에 보관된 객체를 사용하려면 Cache.get() 메소드를 사용하면 된다. Cache.get() 메소드는 키를 파라미터로 전달받으며, 키에 해당하는 Element 객체를 리턴하며 관련 Element과 존재하지 않을 경우 null을 리턴한다. 아래 코드는 Cache.get() 메소드의 사용예이다.

Element.getValue() 메소드는 캐시에 저장된 객체를 리턴한다. 만약 Serializable 하지 않은 객체를 값으로 저장했다면 다음과 같이 Element.getObejectValue() 메소드를 사용하여 값을 구해야 한다.

Delete 작업 수행
Cache에 보관된 객체를 삭제하려면 Cache.remove() 메소드를 사용하면 된다. 아래 코드는 Cache.remove() 메소드의 사용예이다.

Cache.remove() 메소드는 키에 해당하는 객체가 존재하여 삭제한 경우 true를 리턴하고, 존재하지 않은 경우 false를 리턴한다.

CacheManager의 종료

사용이 종료된 CacheManager는 다음과 같이 shutdown() 메소드를 호출하여 CacheManager를 종료해야 한다.

Cache 값 객체 사용시 주의사항

캐시에 저장되는 객체는 레퍼런스가 저장된다. 따라서, 동일한 키에 대해 Cache.put()에 전달한 Element의 값과Cache.get()으로 구한 Element의 값은 동일한 객체를 참조하게 된다.

위 코드에서 Cache.put()에 전달된 element 객체와 Cache.get()으로 구한 elementFromCache 객체는 서로 다른 객체이다. 하지만, 두 Element 객체가 갖고 있는 값은 동일한 객체를 참조하고 있다. 따라서, 캐시에 값으로 저장된 객체를 변경하게 되면 캐시에 저장된 내용도 변경되므로, 캐시 사용시 이 점에 유의해야 한다.

캐시 설정

캐시 설정 파일에 <cache> 태그를 이용하여 캐시를 설정했었다. 캐시 설정과 관련하여 <cache> 태그는 다양한 속성을 제공하고 있는데, 이들 속성에는 다음과 같은 것들이 존재한다.

아래 코드는 몇 가지 설정 예이다.

분산 캐시

EHCache는 분산 캐시를 지원한다. EHCache는 피어(peer) 자동 발견 및 RMI를 이용한 클러스터간 데이터 전송의 신뢰성 등 분산 캐시를 위한 완전한 기능을 제공하고 있다. 또한, 다양한 옵션을 통해 분산 상황에 맞게 설정할 수 있도록 하고 있다.

참고로, EHCache는 RMI를 이용하여 분산 캐시를 구현하고 있기 때문에, Serializable 한 객체만 분산 캐시에서 사용 가능하다. 키 역시 Serializable 해야 한다.

분산 캐시 구현 방식

EHCache는 한 노드의 캐시에 변화가 생기면 나머지 노드에 그 변경 내용을 전달하는 방식을 사용한다. 즉, 클러스터에 있는 캐시 인스턴스가 n개인 경우, 한번의 변경에 대해 n-1개의 변경 통지가 발생한다.

각 노드의 캐시간 데이터 전송은 RMI를 통해서 이루어진다. EHCache가 데이터 전송 기술로서 RMI를 사용하는 이유는 다음과 같다.

• 자바에서 기본적으로 제공하는 원격 메커니즘
• 안정화된 기술
• TCP 소켓 옵션을 튜닝할 수 있음
• Serializable 한 객체를 지원하기 때문에, 데이터 전송을 위해 XML과 같은 별도의 포맷으로 변경할 필요가 없음

노드 발견

EHCache는 클러스터에 새로운 노드가 추가돌 경우 해당 노드를 자동적으로 발견하는 방식과, 지정된 노드 목록에 대해서만 클러스터의 노드로 사용하는 방식을 지원하고 있다.

멀티캐스트 방식

멀티캐스트 모드를 사용한 경우, 지정한 멀티캐스트 IP(224.0.0.1~239.255.255.255)와 포트에 참여하는 노드를 자동으로 발견하게 된다. 지정한 IP와 포트에 참여한 노드는 자기 자신을 다른 노드에 통지한다. 이 방식을 사용하면 클러스터에 동적으로 노드를 추가하거나 제거할 수 있다.

노드 목록 지정 방식

클러스터에 포함되는 노드 목록을 지정한다. 동적으로 새로운 노드를 추가하거나 기존 노드를 제거할 수 없다.

분산 캐시 설정

분산 캐시를 사용하기 위해서는 다음과 같은 세 개의 정보를 지정해주어야 한다.

• CacheManagerPeerProvider - 피어 발견 관련 설정
• CacheManagerPeerListener - 메시지 수신 관련 설정
• 캐시별 CacheReplicator - 메시지 생성 규칙 설정

CacheManagerPeerProvider 설정

CacheManagerPeerProvider는 새롭게 추가된 노드를 발견하는 방식을 지정한다.

노드를 자동으로 발견하는 멀티캐스트 방식을 사용하려면 다음과 같이 설정한다.

위 코드에서 properties 속성의 값에 사용된 프로퍼티는 다음과 같다.

하나의 클러스터에 포함될 노드들은 동일한 멀티캐스트 IP와 포트 번호를 사용해야 한다.

클러스터에 참여할 노드 목록을 지정하는 IP 방식을 사용하려면 다음과 같이 설정한다.

위 코드에서 properties 속성의 값에 사용된 프로퍼티는 다음과 같다.

이 경우, rmiUrls에 명시된 포트 번호는 뒤에 살펴볼 CacheManagerPeerListener가 사용할 포트 번호를 지정해주어야 한다.

CacheManagerPeerListener 설정

노드를 발견하는 방식을 지정했다면, 다음으로 할 작업은 클러스터에 있는 다른 노드에서 발생한 변경 정보를 수신할 때 사용할 포트 번호를 지정하는 것이다. 다음과 같은 코드를 이용하여 수신과 관련된 포트 번호를 설정할 수 있다.

위 코드에서 properties 속성의 값에 사용된 프로퍼티는 다음과 같다.

캐시별 CacheReplicator 설정

분산 환경에 적용되어야 하는 캐시는 캐시의 내용이 변경되었을 때 다른 노드에 있는 캐시에 변경 내역을 알려주어야 한다. <cacheEventListenerFactory> 태그를 사용하면, 언제 어떻게 캐시의 변경 내역을 통지할지의 여부를 지정할 수 있다. 아래 코드는 설정의 예이다.

위 코드와 같이 <cacheEventListenerFactory>의 구현 클래스로 RMICacheReplicatorFactory를 지정하면 캐시에 변경이 생길 때 마다 해당 변경 내역을 클러스터에 참여하고 있는 노드의 캐시에 통지하게 된다. properties 속성에 프로퍼티를 지정하면, 캐시 요소의 추가, 변경, 삭제 등에 대해 통지 방식을 적용할 수 있다. 설정할 수 있는 프로퍼티는 다음과 같다.

위 속성의 기본값은 모두 true이다. 따라서, 기본 설정값을 사용하려면 다음과 같이 properties 속성을 사용하지 않아도 된다.

어플리케이션 구동시 캐시 데이터 로딩하기

CacheManager가 초기화 될 때, 클러스터에 있는 다른 캐시로부터 데이터를 로딩할 수 있다. 이는 초기 구동이 완료된 후 곧 바로 서비스를 제공할 수 있음을 의미한다. 초기 구동시 다른 노드로부터 캐시 데이터를 로딩하려면 다음과 같이 <bootstrapCacheLoaderFactory> 태그의 구현 클래스를 RMIBootstrapCacheLoaderFactory로 지정해주면 된다.

RMIBootstrapCacheLoaderFactory에 전달 가능한 프로퍼티 목록은 다음과 같다.

RMIBoostrapCacheLoaderFactory를 설정하면 캐시를 초기화 할 때, 원격지 노드의 캐시에 저장된 데이터를 로딩하여 로컬 캐시에 저장한다.

분산 캐시 고려사항

분산 캐시를 사용할 때에는 다음과 같은 내용을 고려해야 한다.

• 노드 증가에 따라 네트워크 트래픽 증가:
  많은 양의 네트워크 트래픽이 발생할 수 있다. 특히 동기 모드인 경우 성능에 영향을 받을 수 있다. 비동기 모드인 경우 버퍼에 변경 내역을 저장하였다가 일정한 주기로 버퍼에 쌓인 내역을 다른 노드에 통지하기 때문에 이 문제를 다소 완하시킬 수 있다.
• 데이터 불일치 발생 가능성:
  두 노드에서 동시에 동일한 캐시의 동일한 데이터에 대한 변경을 수행할 경우, 두 노드 사이에 데이터 불일치가 발생할 수 있다. 캐시 데이터의 불일치가 매우 심각한 문제가 될 경우, 동기 모드(replicateAsynchronously=false)와 복사 메시지 대신 삭제 메시지를 전송(replicateUpdatesViaCopy=false)함으로써 이 문제를 해결할 수 있다.

관련링크:

• EHCache

자바 디자인 패턴 6 - Strategy

출처 : http://iilii.egloos.com/3826810

참고 및 출처 ::

 - http://www.buggymind.com/36

 - http://pupustory.tistory.com/161

* Facade Pattern (퍼사드 패턴)

퍼사드 패턴은 디자인 원칙의 최소 지식 원칙을 준수하는 패턴으로써 클라이언트를 복잡한 서브 시스템과 분리시켜주는 역할을 한다. 무슨 말인고 하니, 서브 시스템을 가지고 퍼사드를 만들고 실제 작업은 서브 클래스에 맡긴다는 뜻이다.

* 예제

어항을 청소한다고 생각해보자. 먼저 물고기를 옮기고, 어항 안에 악세사리를 꺼내고, 물을 제거한 후 어항을 청소하고, 다시 악세사리를 넣고 물을 채우고 물고기를 넣는다. 이를 메소드 호출로 생각한다면 아래와 같을 것이다.

이러한 어항 청소 프로세스를 하나의 메소드 또는 인터페이스로 정의한 다음 서브 시스템에서 최소한의 지식만 가지고 사용할 수 있도록 하는 것이 퍼사드 패턴이다.

* 퍼사드 패턴 적용

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

doWash() {     // 물고기를 꺼내고     getFish();       // 악세사리를 꺼내고     getDecorator();       // 물을 비우고     getWater();       // 어항을 청소하고     wash();       // 악세사리를 설치하고     setDecorator();       // 물을 넣고     setWater();       // 물고기를 넣는다.     setFish(); }

 

물론 많은 부분이 생략되었지만 아래 다이어로그램을 참고한다면 어떤식으로 적용해야 할지 알 것이다.

실제로 퍼사드 패턴은 우리가 이미 자주 사용하고 있는 패턴 중 하나이다. 클라이언트는 캡슐화된 프로세스 내의 동작을 알 필요 없이 해당 인터페이스가 요구하는 정보만 넣어서 호출하면 원하는 결과를 얻을 수 있도록 한다. 한 마디로 복잡한 클래스들과 패키지들을 어떤 단순한 인터페이스 객체 뒤에 감추는 것이다. 

예를 들어 Java의 Date 클래스는 사실 사용하기가 좀 까다롭다. 그런 복잡한 사용 방법은 전부 다 감추고, 사용자로 하여금 단순히 '현재 날짜에 며칠을 더하면 언제가 되는지' 알려주는 인터페이스만 주고 싶다고 하자.

그러면 퍼사드 클래스를 설계해서, 그 클래스가 내부적으로 Date 클래스나 기타 관련 클래스들을 조작하게 한 다음, 퍼사드 클래스가 제공하는 인터페이스만 사용하도록 하면 된다. 결국 이렇게 해서 만들어진 퍼사드 클래스는 Date 클래스에 대한 '대안적'인 인터페이스가 되는 것이다.

따라서 퍼사드 패턴은 어떻게 보면 어댑터 패턴하고도 비슷하나 Adaptation할 기능의 규모가 좀 더 큰 경우에 보다 적합하다고도 할 수 있다.

출처 : 

http://warmz.tistory.com/764

이클립스 UML 그리기 미션!!

인디고 버젼 설명~~~~

Install New Software...  -> Indigo - http://download.eclipse.org/releases/indigo 선택!!

Modeling -> EMF, GMF SDK 설치!!
 

http://www.soyatec.com/euml2/installation/offline.php#offline
 접속 후 버젼에 맞는(indigo) 파일 다운로드!!(eUML2 Free Edition 3.7.1.20110624 + required plugins for Indigo/Eclipse 3.7.x)

다시 install.......... -> Add -> Name 쓰시고 Archive 클릭!! 후 다운 받은 압축파일 경로로 지정

eUML2 Free Edition 설치!!!  Modeler Documentation 설치 시 오류 발생 경험............

완료~ 패키지 선택 시 아래 버튼이 활성화 되어 UML 그릴 수 있음..

출처 : http://lovelyhun.tistory.com/38

출처 : http://javacan.tistory.com/entry/

인터셉터는 필터와 유사한 동작을 한다. 요청이 controller 에 전달되고 또는 나가는 시점에 요청, 또는 응답을 가로채어 원하는 작업을 수행해줄 수 있다.

 인터셉터에서 사용할 수 있는 세 가지 메소드는 preHandler,  postHandle,  afterCompletion 이다.

preHandle() 메소드는 요청이 controller에서 들어가기 전, poastHandle()은 요청이 controller에 의해 처리되고, 뷰로 보내지기 전,

afterCompletion() 메소드는 뷰까지 보여지고 난 후, 필요한 작업을 수행할 수 있다. 마치 AOP와 조금 유사한 모습을 보이고 있다.

- preHandle : 클라이언트의 요청을 컨트롤러에 전달하기 전에 호출됨. false를 리턴하면 다음 내용은 실행하지 않는다.
- postHandle : 클라이언트의 요청을 처리한 뒤에 호출됨. 컨트롤러에서 예외가 발생되면 실행하지 않는다.
- afterCompletion : 클라이언트 요청 처리뒤 클리이언트에 뷰를 통해 응답을 전송한뒤 실행 됨. 뷰를 생설항때 예외가 발생해도 실행된다
 

아래는 urlHandlerMapping에 인터셉터를 인젝션해주고 있다. 이 맵핑이 정의하는 url로 들어오는 요청은 인터셉터에 의해 가로채진다.

1. <!-- Member : 로그인한 사람 허용 -->
    <bean id="memberSecureUrlHandlerMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
        <property name="interceptors">
            <list>
             <ref bean="loginCheckInterceptor"/>
            </list>
        </property>
        <property name="urlMap">
            <map>
             <entry key="/member/edit.do" value-ref="memberSimpleFormController"/>
             <entry key="/member/logout.do" value-ref="memberMultiActionController"/>
         </map>
        </property>
    </bean>

 아래는 preHandler()  메소드를 사용하여, session을 검사하여 로그인 체크를 하고 있다. 로그인이 되지 않은 요청이면, 요청을 끝내버리고,

로그인 된 요청이면 컨트롤러에게 요청이 전달될 것이다. 인터셉터에서 반환된 요청에 의해 웹브라우저에서는 하얀 화면이 보여질 것이다.

1. public class LoginCheckInterceptor extends HandlerInterceptorAdapter {
2.  private String sessionUserIdKey;
      ....
3. 
    // 로그인 했는지 체크
   
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        HttpSession session = request.getSession(false);
        if (session == null) {
         // 처리를 끝냄 - 컨트롤로 요청이 가지 않음
         return false;
     }
4. 
     String userId = (String)session.getAttribute(this.sessionUserIdKey);
        if (userId == null) { 
         return false;
        }
     return true;
    }
    
    
    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
    
        super.postHandle(request, response, handler, modelAndView);
    }
    
    
    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {

5. super.afterCompletion(request, response, handler, ex);

6.   }
7. }

Spring MVC - Annotation Base HandlerInterceptor

Spring core에서는 AOP를 이용하여 처리내용의 전, 후에 일괄적으로 적용하고 싶은 처리를 추가할수가 있다. 하지만 AOP는 interface를 구현한 곳에만 사용할 수가 있습니다. 그래서 Spring MVC의 Controller에는 상용할수 없죠 자 그럼 만약 로그인 체크를 해야한다면 모든 Controller에 로그인 체크 로직을 넣어줘야할까?. 아니다! 그럼 상위 Controller를 만들고 여기에 로그인 체크로직을 넣고 모든 Controller가 이를 상속 받아 쓰면 어떨까. 그남아 났군.. 이런 것을 위해 Spring MVC 에서는 HandlerMapping이 HandlerInterceptor를 이용하해서 Controller가 요청하는 처리의 전과, 후후에 원하는 기능을 수행할수 있도록 해준다고한다.  ( 뭐 깊숙한 내용까지 알려면 더 공부를하고, 아니면 그냥 Controller에서도 AOP와 같이 쓸수 있도록 제공해준다고 알자 ) HandlerInterceptor는 세가지 메소드를 정의한다

접기

- preHandle : 클라이언트의 요청을 컨트롤러에 전달하기 전에 호출됨. false를 리턴하면 다음 내용은 실행하지 않는다. - postHandle : 클라이언트의 요청을 처리한 뒤에 호출됨. 컨트롤러에서 예외가 발생되면 실행하지 않는다. - afterCompletion : 클라이언트 요청 처리뒤 클리이언트에 뷰를 통해 응답을 전송한뒤 실행 됨. 뷰를 생설항때 예외가 발생해도 실행된다. Interceptor의 구현 org.springframework.web.servlet.HandlerInterceptor 를 직접 구현해서 클래스를 작성해도 되지만 이러면 세개의 메소드를 모두 구현해야한다. 즉 preHandle 만 필요해도 postHandle과 afterCompletion 두 메소드를 모두 구현해야한다. 이를위해 Spring에는 HandlerInterceptorAdaptor 클래스를 제공한다. 이는 이미 HandlerInterceptor interface를 구현한 클래스로 위의 세개의 메소드를 이미 구현하고 있어 필요한것만 구현해서 사용하면 된다. - Interceptor 구현

- dispatcher-servlet.xml의Interceptor 설정

위와 같이 할때는 모든 페이지 URL에서 userLoginInterceptor를 실행하게 된다. 그리고  <list>    <ref bean="userLoginInterceptor"/>     <ref bean="userLoginInterceptor2"/>     <ref bean="userLoginInterceptor3"/> </list> 과 같이 여러 인터페이스를 줄수도 있다.