Your implementation sounds very similar. We too created an aspect around the service facade and use thread locals to store the current principal. We also wanted to keep track of who was calling who (for example, in some situations it is important for us to know when the client is calling a service method or when one service is calling another service's method), so we also maintain a ThreadLocal stack and use a recursive foreign key in our service method audit table. We also provide the option, for specified services, to disable tracking the call stack, in which case only the top level service method gets audited (any methods invoked by that method are simply ignored). I should note that in our architecture, it is often the case that one service needs to invoke another - and in such cases, the reference to the other service is injected by Spring, and of course, the reference is the proxied reference and not the raw target. The only other "aspect", so to speak, that we created was a Hibernate interceptor for data operation logging.
- Andy On Tuesday 21 December 2004 10:09 am, Seth Ladd wrote: > Interesting, sounds pretty similar. We didn't need to audit every > parameter, though. > > We created an AuditLog Aspect to wrap our Service Facade. This was a > logical place for us, because the Facade has a method for every use case. > > We created a Filter to put the current Principal into a ThreadLocal > (much like what Acegi does, but we're not using Acegi (yet)). > > The AuditLog Aspect then grabs the Principal from the ThreadLocal, > combines with the Method invocation, and writes it to DB. > > The tricky part, and turns out easily solvable, was to determine the > actual primary object being operated on. > > We would have a service method such as: > > resetPassword(Long id) > > or > > recoverPassword(String username, String email) > > We needed to examine either the return values, or parameters, to find > out what the "it" is we're working on. So we created some heuristic > classes that can examine the return value or parameters to determine the > object id. This lets us tie these audit log events back to some object > in the system. > > So, you can see, when we call remote methods via Hessian (or the like) > we needed to propogate that Principal for audit logging to work. > > Seth ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
