Announcement Announcement Module
No announcement yet.
Configuring object with per user info Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Configuring object with per user info


    I haven't tried to do this yet, but does anybody know the correct idiom for doing the following.

    Normally when I make a data access object it gets passed a DataSource, which is configured with username etc gotten from eg. config file.

    But what if I need my DAO to be configured for each user with their credentials?
    And the DataSource was just an example, I mean how is this supposed to be done with any resource (some general pattern), like LDAP etc. so that each user gets the "Manager" configured to access the underlying resource with his own credentials.

    A solution using servlet APIs would be fine, of course better if it's more general.
    In WebWork this kind of works by using (http)session scoped objects.

    It would also be nice if the resource would be created once per session (so that a possible connection would't be done on every request)

  • #2
    Hum, apparently this isn't possible, or not that important

    Seriously, hasn't anybody run into this problem?


    • #3
      Take a look at org.springframework.jdbc.datasource.UserCredential sDataSourceAdapter
      This class is an adapter that apply user credentials for current thread and use these credentials for each getConnection.
      You can create simillar adapters for LDAP...


      • #4
        Thank you, looks promising at first glance.
        I had a problem similar to this earlier, and solved it using webwork IoC (which seems kind of spartan compared to spring)


        • #5
          On a general basis, if you need to do per-user scoping if resource usage, one technique is to associate the user specific info as a threadlocal variable, and then use it later. If you look at the Acegi Security Framework for example, coming in, it binds a SecurityContext security context object to the current thread, and then that is later (in the call graph) able to be used to do actions that rely on that user specific data...