Announcement Announcement Module
Collapse
No announcement yet.
Scoped bean lifecycle management Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Scoped bean lifecycle management

    I am reading, with interest, about request & session scoped beans.
    They seem to promise a better solution to the one that I'm currently employing, but I can't seem to find any way of doing the following.

    Provide a BeanPostProcessor style hookpoint that is invoked specifically when a bean is created in a particular scope. This post processor would be supplied, in addition to the bean and it's name, a reference to the scope that the bean was instantiated in.

    The reason that I wan't to be able to do this is so that the bean can have further injections, based on information which is relevant to the scope but cannot be described in the context file (The session Id, for example)

    Is such a mechanism available, if not, is it one that you would consider adding?

  • #2
    Hi belugabob

    Good name there. Anyways, no, no such functionality exists in the current codebase.

    It would not be hard to implement such a scope-aware BPP yourself though. The bean name is supplied to all of the methods in the BPP interface, and as such allows one to get at the underlying bean definition (which contains the scoping information), and from then one an have a number of template methods for parricular scopes.

    Cheers
    Rick

    Comment


    • #3
      Rick,

      Thanks for the reply - my issue is not so much hooking up a BPP but having a reference to the scope in which the bean was instantiated (Session, request etc) so that the bean can be initialized further, based upon the scope.
      The current BPP implementations only get the bean and its name.

      Bob

      As for the 'belugabob' name, that is - as they say - 'A long story'

      Comment


      • #4
        Hi

        Indeed, the BPP interface only supplies the bean name and the object.

        The fact that one gets the bean name is key. Given the bean name, one can do a lookup in the container of the associated bean definition. Given the bean definition one can then ascertain the scope of that particular bean. Given the scope of the bean, one can then access the underlying storage mechanism (the HTTP Session for example), and then one can, in your case, access the id of the session and supply it to the bean instances(s) as you see fit.

        I'll whip up a demo over the weekend (chock a block busy today), or perhaps Costin will step into the breach

        Cheers
        Rick

        Comment


        • #5
          Thanks for the offer - I'll look forward to you reply on Monday(ish)

          Not sure what you mean by
          Given the scope of the bean, one can then access the underlying storage mechanism (the HTTP Session for example),
          How do you get the HttpSession from the scope that is specified in the bean definition - isn't this just a string?

          Curiously awaiting your solution.

          Comment


          • #6
            Hi belugabob

            Find attached just the Java source files and Spring XML configuration files that implements the functionality you are looking for. The relevant classes are named ScopeAwareBeanPostProcessor and WebScopeAwareBeanPostProcessor respectively (some extra - trivial (one line) - web.xml configuration is also required in the case of the WebScopeAwareBeanPostProcessor). (I can send the whole web app if you'd like.)

            Spring's web infrastructure does actually bind the HTTP request to the current thread, but unfortunately does not provide a means to actually get at it. As a result I had to implement my own (c.f. RequestAccessor and HttpRequestProvidingListener). Bah All for lack of a simple getter.

            Hope that helps, cheers
            Rick

            Comment


            • #7
              Rick,

              Thanks for taking the time to put the sample code together.
              I've had a quick look and it all seems to make sense to me - the thing that I was missing was the whole HttpRequestProvidingListener/RequestAccessor business.

              Anyway, I'll incorporate this into a test application later this week - I'm tied up with another task this week (And I'm not currently using Spring V2 in any of my projects, as it's still not quite a stable release)

              I will let you know how I get on - If this works out as expected, I can see a good argument for these classes to be added to the core framework.

              Thanks again.

              Bob

              Comment


              • #8
                Originally posted by Rick Evans
                Find attached just the Java source files and Spring XML configuration files that implements the functionality you are looking for
                Hey Rick,

                Thanks for the contribution. I'm trying to run your example code, it seems you've left out a few java source files in your zip.

                Code:
                Missing Classes:
                forums.scope.domain.Recipe
                forums.scope.web.SwitchBoardController
                forums.scope.web.EditRecipeController

                Comment


                • #9
                  Hi Steve

                  Originally posted by robododge
                  ... it seems you've left out a few java source files in your zip.
                  Indeed. I just packaged those files that addressed belugabob's issue directly. If you want to get access to the whole shebang you can find the relevant source in the '/samples/showcases/mvc-convention/' directory of the 'spring-with-dependencies.zip' bundle of the Spring distribution. You will have to mangle some package names and suchlike but the meat and bones are all there.

                  (I'd send the full app, but obsessive compulsive that I am I deleted the original source after zipping up the stuff for belugabob )

                  Cheers
                  Rick

                  Comment

                  Working...
                  X