Announcement Announcement Module
Collapse
No announcement yet.
User information in the service layer Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • User information in the service layer

    Hi all,

    I'm wondering if anyone has any ideas as to how one might go about propogating user information from the web layer down to the service layer without having to pollute the service layer interfaces with extraneous User parameters.

    To give you some background, I basically have a 'updateCustomer(Customer customer)' method in my service layer object. This obviously doesn't have anything directly to do with the user. However, we also have a requirement that certain people are to be notified via email whenever such an update is performed. Amongst other things, one of the items to be included in the email is the name of the user who triggered the update.

    Now it seems to me that this is a pretty good opportunity to use Spring AOP. Before the method is invoked, I can retrieve the pre-update state (so that the changes can be highlighted in the email), then the method can execute, then I can compose and send the email. No email related code in the service method implementation. The problem is that without access to the HttpSession where the user's ID is stored, I don't have a way of getting the user information.

    Bearing in mind that we aren't using Spring MVC, does anyone have any suggestions as to how the aspect code could see who the user is? One option that I considered was simply setting a ThreadLocal variable while checking the user's permission to access the page and then retrieving it in the service layer. However, this approach seems a little messy. Another option that came to mind was to use non-singleton service implementations and to set the user information in the service layer object instances as they are being retrieved from the ApplicationContext. This approach doesn't seem quite right to me either, though I'd be interested to know if other people are doing this.

    Any ideas and suggestions would be welcome.

    Geoff

  • #2
    I would not pick service objects as non-singletons as that will change the behaviour of your system (like transactions covering multiple services).

    You could create a new context for each user, that works fine but does have a performance impact and limits communication between users (using Spring's event model).

    I prefer the ThreadLocal solution, it's not messy as you can do this at session creation time, you don't have to re-do it on every page request and works in all cases (and not just in a web context). For example, I use this to get the user information so I can send emails (same as you), but I use the same ThreadLocal to populate auditing information in my datatabase (a lastUpdatedBy field).

    Cheers
    Steve

    Comment


    • #3
      Thanks for the good input, Steve. I guess the advantage of the ThreadLocal solution is that it is usable at all layers of the application that the thread will pass through. However, I'm a little confused as to what you mean by doing it at session creation time rather than on each page request. Perhaps you could explain that a little?

      Geoff

      Comment


      • #4
        You wrote:

        The problem is that without access to the HttpSession where the user's ID is stored
        and

        setting a ThreadLocal variable while checking the user's permission to access the page
        I took that to mean that you reset the ThreadLocal within your code (during your permissions checking). I wasn't clear enough though, I think we set our ThreadLocal as part of the servlet filter chain defined in the web.xml file. I think it get's set on each request, but it's not tied into any user code (like security checking code) that may not get invoked in every context you want the ThreadLocal.

        Cheers

        Comment


        • #5
          Ah, I see where you're coming from now. We're still stuck on J2EE 1.2 (yes, I pity myself too), so I don't have the benefit of filters yet, but I am able to set the ThreadLocal variable in the one place without having other servlet developers needing to worry about it.

          Geoff

          Comment


          • #6
            Originally posted by luxaeterna
            Ah, I see where you're coming from now. We're still stuck on J2EE 1.2
            I feel for you man! :cry:

            Comment

            Working...
            X