Announcement Announcement Module
Collapse
No announcement yet.
Need to apply user-specific values to Spring-managed beans Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Need to apply user-specific values to Spring-managed beans

    I have a set of beans that are configured using a Spring XML application context as non-singletons. In some cases, I need to apply user-specific data to these beans before calling aertain method on them. A complicating factor is that the beans I am retrieving may be Objects of any type and therefore may be Collections, and may be nested several layers deep (i.e. Collections of Collections).

    I am looking for the cleanest / most transparent way to do this. In some cases, it would be sufficient to retrieve my top-level bean from the app context, and apply my user-specific data programmatically. In cases where the context data is needed on beans nested inside the "top level" one retrieved, this would be insufficient. I am hoping there is a cleaner/better way to do this.

    It seems to me that a nice solution would be a callback/event-based mechanism where a listener/callback registered against the app context upon lookup would get notified whenever a bean is instantiated and the listener could decide if it should apply the user-specific data. However, it doesn't seem like there is support for this since no "BeanInstantiationEvent" is published by the container, and I don't know of a way to register a per-lookup listener/callback.

    Another option would be a parameterized bean lookup mechanism where I could pass my user specific object as part of the application context lookup and the container would apply it if required (i.e. if it implements some particular interface). I could probably achieve this reasonably easily by subclassing one of the ApplicationContexts. This would probably not deal with nested beans very well though.

    In the past, I have created per-user application contexts using servlet filters and ThreadLocals to address user-specific configurations but this was pretty ugly.

    Any ideas / suggestions are appreciated.

    Thanks!

    Shea.

  • #2
    You mention ThreadLocals, so I might as well point out Acegi Security CVS and 0.8.0 onward (to be released early next week) offers a much-improved ThreadLocal service via its ContextHolder. We've used ContextHolder since the first release for storing Authentication information, and whilst it's always been extensible, 0.8.0 makes that extensibility highly practical and easy. Perhaps take a look in CVS, as if your main concern is ThreadLocal management being ugly, this will solve it for you. As a bonus, our RMI invoker and HttpInoker respectively directly support and can be easily customised to transport client-side Context objects to the server-side for the duration of a web request.

    Comment

    Working...
    X