I have scoped my aspect as session, and @Autowired in the current HttpSession so I can do Auditing on a user by user basis. Is there likely to be any issues with this approach?
Thanks
Chris
I have scoped my aspect as session, and @Autowired in the current HttpSession so I can do Auditing on a user by user basis. Is there likely to be any issues with this approach?
Thanks
Chris
An aspect is a kind of "service" and so it should generally be stateless. As such, it would best be defined as a singleton.
In your case, I would:
- create a bean to contain user information. Define it in Spring as a session-scoped bean (adding <aop:scoped-proxy/>), and fill it up as part of the user login process;
- create a statless aspect to do the auditing, and define it in Spring as a singleton bean;
- inject the session scoped bean in the aspect so that the aspect has the user information it requires to work.
But then, the aspect is stateful. You wanted to avoid that.inject the session scoped bean in the aspect so that the aspect has the user information it requires to work.
Did I misunderstood something?
I would just create a pointcut matching the session-scoped user bean, for instance.
No, it is not. The aspect IS a stateless bean. A statless bean cannot ever BECOME stateful, it either is or is not stateless. You probably misunderstood the concept of state in a bean.But then, the aspect is stateful.
It depends on what kind of auditing the original poster wanted to achieve. With your solution, you could only audit accesses to the user session bean, which can be limited. With my solution you can audit pretty much everything, and use the user session bean to add user profile information to the auditing. I also think it is a cleaner solution.I would just create a pointcut matching the session-scoped user bean
this sounds interesting!
Could you elaborate a little bit more on it?
As far as I understood, the aspect intercepts more or less everything the user triggers or operates on and then writes a kind of log to the user bean.