开发者

Passing presentation (Struts) parameters to (Spring) ApplicationContext and use them in Hibernate Interceptor

开发者 https://www.devze.com 2023-04-05 03:20 出处:网络
I\'m sorry for the long title, but I knew no other way to be specific. What I have: I\'m developing an Audit Trail module that uses a Hibernate Interceptor to intercept Hibernate calls and add audit

I'm sorry for the long title, but I knew no other way to be specific.

What I have:

I'm developing an Audit Trail module that uses a Hibernate Interceptor to intercept Hibernate calls and add audit log entries. This works fine.

My web application uses Struts2 and Spring. My Hibernate Interceptor has access to Spring's ApplicationContext.

What I want:

Because I want to "give meaning" to each audit log entry, I need to pass parameters (such as a String message) on each request made at presentation layer (Struts), to Spring's ApplicationContext. That way, I can access the parameter in Hibernate Interceptor and log it accordingly.

Example:

  1. Struts - User details page: setPassword(user1, mypass), generating a new message "User1 changed his/her password".
  2. This message is injected in Spring's ApplicationContext.
  3. Hibernate Interceptor intercepts the "update" and gets the previous message from Spring's ApplicationContext, creating a new log entry with the mess开发者_StackOverflow社区age.

Do you know how to do this?


I assume you use the Struts2 Spring plugin to integrate both. When using this, your Struts actions, interceptors are build by a Spring object factory and hence can benefit from dependency injection of Spring beans.

On the Spring side one way could (I haven't tried) work: using request scoped beans like this:

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

The Spring container creates a new instance of the bean by using the myBean bean definition for each and every HTTP request.

On Struts side (your action or custom interceptor) you can now inject the Spring bean and set your information. You have to be aware that your bean now has state (the information you gave).

On Hibernate side you should now be able the get the bean from the context as well and read the information and log it.

As an alternative you mighty think about using a MDC (Mapped Diagnostic Context) like described here for the LOGBack logging framework. With MDC you can very easily put values like MDC.put("myKey", "myValue") and have it logged with a custom pattern like %X{myKey}. This solution would bypass your Hibernate interceptor at all.


I thought Hibernate already knew which fields were dirty, but I could be mis-remembering. In any case, I'm not sure this is the best way to go about this.

I'd take a different approach and do this in the service/service call itself rather than relying on the Hibernate interceptors. IMO the Hibernate interceptors are too low in the "conceptual" application. The services, OTOH, already act as a bridge between the view layer and the data layer.

Since you (a) already need to "manually" interact with the service layer, and (b) the Hibernate interceptors don't have a trivial view into the application (nor, IMO, should they, but that's just my opinion :) I'd move the auditing up a layer of abstraction.

(I'm aware this is less of an answer and a redirection, but it was too long for a comment.)

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号