2011-09-16 5 views
1

긴 제목은 유감이지만 구체적인 방법은 없습니다.(Spring) ApplicationContext에 프레젠테이션 (Struts) 매개 변수를 전달하고 Hibernate 인터셉터에서 사용합니다.

내가 무엇을 가지고 :

내가 최대 절전 모드 호출을 차단하고 감사 로그 항목을 추가 하이버 네이트 인터셉터를 사용하는 감사 추적 모듈을 개발하고 있어요. 이것은 잘 작동합니다.

내 웹 응용 프로그램은 Struts2와 Spring을 사용합니다. 내 Hibernate 인터셉터는 Spring의 ApplicationContext에 접근 할 수있다.

내가 원하는 무엇 : 나는 각 감사 로그 항목에 "의미를 부여"싶기 때문에

, 나는 프리젠 테이션 계층에서 만들어진 각각의 요청에 따라 (예 : 문자열 메시지 등) 매개 변수를 전달해야합니다 (스트럿츠) , Spring의 ApplicationContext. 그렇게하면 Hibernate Interceptor의 매개 변수에 액세스하여 그에 따라 기록 할 수 있습니다.

예 :

  1. 스트럿츠 - 사용자 세부 사항 페이지 : SETPASSWORD 새로운 메시지를 생성 (USER1, mypass)은 "사용자 1은 그/그녀의 암호를 변경 한".
  2. 이 메시지는 Spring의 ApplicationContext에 삽입된다.
  3. Hibernate Interceptor는 "update"를 가로 채고 Spring의 ApplicationContext에서 이전 메시지를 가져 와서 메시지와 함께 새로운 로그 항목을 생성한다.

어떻게하는지 알고 계십니까?

답변

1

난 당신이 Struts2 봄이 둘을 통합하는 플러그인을 사용하는 가정합니다. 이것을 사용할 때, Struts 액션 인 인터셉터는 Spring 객체 팩토리에 의해 빌드되므로 스프링 빈의 의존성 주입의 이점을 얻을 수 있습니다. 이 같은 request scoped beans를 사용하여 : :

<bean id="myBean" class="com.foo.MyBean" scope="request"/> 

스프링 컨테이너가 myBean 빈 정의를 사용하여 빈의 새로운 인스턴스를 생성하는 봄 측 (나는 시도하지 않은) 수있는 하나의 방법 일에

각각의 모든 HTTP 요청에 대해

Struts 측 (액션 또는 커스텀 인터셉터)에서 이제 스프링 빈을 주입하고 정보를 설정할 수 있습니다. 빈이 이제 상태 인 (사용자가 제공 한 정보)이라는 사실을 알아야합니다.

최대 절전 모드에서는 컨텍스트에서 Bean을 가져 와서 정보를 읽고 로그 할 수 있어야합니다.

here for the LOGBack logging framework과 같이 MDC (매핑 된 진단 컨텍스트)를 사용하는 것이 좋습니다. MDC를 사용하면 MDC.put("myKey", "myValue")과 같은 값을 쉽게 입력 할 수 있으며 %X{myKey}과 같은 사용자 정의 패턴으로 로그에 기록 할 수 있습니다. 이 해결책은 당신의 Hibernate 인터셉터를 전혀 무시할 것이다.

+0

정말 고맙습니다. 나는 "요청"범위를 성공적으로 사용했다. – anahnarciso

1

Hibernate는 어떤 필드가 더러운 지 이미 알고 있다고 생각했지만 잘못 기억하고있을 수 있습니다. 어쨌든, 이것이 이것이 가장 좋은 방법이라고 확신하지 못합니다.

나는 Hibernate 인터셉터에 의존하기보다는 서비스/서비스 호출 자체에서 다른 접근 방식을 취할 것이다. IMO Hibernate 인터셉터는 "개념적"어플리케이션에서 너무 낮다. 서비스 인 OTOH는 이미 뷰 레이어와 데이터 레이어 사이의 다리 역할을합니다.

당신이 이미 서비스 레이어와 "수동으로"상호 작용할 필요가 있고 (b) Hibernate 인터셉터가 어플리케이션에 대한 사소한 시각을 갖지 못했기 때문에 (IMO도 그렇다), 단지 의견 : 나는 추상화의 계층을 감사를 옮길 것이다.

는 (나는이 대답하고 리디렉션의 작은 알고 있어요,하지만 주석 너무 길다.)

+0

옵션이 아니었지만 어쨌든 고맙습니다. – anahnarciso

+1

@anahnarciso 물론 AOP를 사용 했더라도 그것은 더 깨끗한 것이 었습니다. 응용 프로그램 전반의 동작을 특정 구현에 묶는 것은 거의 항상 나쁜 생각이며 테스트를 훨씬 어렵게 만듭니다. –

관련 문제