Announcement Announcement Module
Collapse
No announcement yet.
How does prototype scope work? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How does prototype scope work?

    This might be quite a naive question but I have to ask. I have consulted the docs also.

    I know that if you have prototype bean B set inside singleton bean A then A must use lookup method injection. Am I correct? It works for me anyway.

    My question, is however, how exactly does the prototype scope work inside Spring? Is prototype B instantiated once and deep copies supplied many times or is it instantiated and supplied many times?

    Also, is there any discernible advantage to setting an object as a prototype bean instead of just instantiating it directly in the code where it is required or instantiating it directly into a class member variable?

    I would be grateful for any insight. Thanks.

  • #2
    No deep copies or lookup method injection take place in this case.

    In Spring there are two distinct concepts: bean and bean definition. A bean may be created any time using the corresponding bean definition. So in case of prototype scope, the definition is each time someone needs it (during context loading).

    -Ramnivas

    Comment


    • #3
      Thanks for reply. I have to clarify though.

      Do you mean that in the case of singleton A containing prototype B that no lookup method injection is necessary? And the bean definition is loaded each time from scratch on every request?

      Comment


      • #4
        No. A is wired with an instance B (permanently, unless some other mechanisms are utilized) . Now if there is another AA that too needs B, it will be wired up with a different instance of B. In short, Spring will create as many instances of B as needed during context loading. Once loaded, there is not much for it to do.

        -Ramnivas

        Comment


        • #5
          Okay that makes sense. So, lastly, is there any advantage to making a bean a prototype rather than instantiating it directly in code? I suppose the only advantage I can think of is that you get to preconfigure the bean with its deps and metadata using spring right?

          Comment


          • #6
            Originally posted by ramnivas View Post
            ... In short, Spring will create as many instances of B as needed during context loading. Once loaded, there is not much for it to do.
            -Ramnivas
            The exception to this would be if new instances of a prototype bean are requested from the context during runtime, right? One case where this is often used is in an MVC framework where each request is supplied with a new instance of a form backing object. In Webwork (and now Spring 2) the action class and the form backing object can be one and the same. In this case, having a singleton scoped bean for the action class would be problematic to say the least. The advantage there of using a prototype scoped bean as opposed to creating the bean manually is that Action classes are often well served by dependency injection.

            Still, I think that a prototype scoped bean could be even more useful if singleton scoped beans could somehow create new instances of prototype beans as needed. This can be done currently either by requesting instances of the bean directly from a BeanFactory, or by using method injection on the Singleton as Narada pointed out, but it feels like their should be a cleaner way, though I'm not sure how.

            Josh

            Comment


            • #7
              Correct (I was trying to keep it simple!). Essentially, every time getBean() is invoked requesting a prototype bean, a new bean instance is created (regardless of who is the caller -- Spring's context loader or user code). It so happens that for beans wired in the application context, the getBean() gets invoked when setting property of another bean. The result is "Spring will create as many instances of B as needed during context loading".

              Other kinds of scopes (session and request, for example) do use create-on-need strategy. In that case, there isn't really another option since sessions and requests are created after the context has been loaded. It gets a bit more complex and interesting due to the need to use proxies.

              -Ramnivas

              Comment


              • #8
                Originally posted by Narada View Post
                Okay that makes sense. So, lastly, is there any advantage to making a bean a prototype rather than instantiating it directly in code? I suppose the only advantage I can think of is that you get to preconfigure the bean with its deps and metadata using spring right?
                Yes, configuring a prototype bean like any other bean is an advantage. Further, a prototype bean may require other (singleton, prototype, or other scopes) beans. It is best to let Spring deal with what it is best at -- dependency injection.

                On project, generally the choice of in-code vs. in-configuration instantiation is pretty clear in a given scenario.

                -Ramnivas

                Comment


                • #9
                  Yeah. In the case of prototype inside singleton what you would intuitively expect to work doesn't work although I'm sure there are those that argue that it behaves exactly as you would expect. I'm not sure if it is possible to somehow have Spring implicitly do what method injection does when it encounters this kind of setup. It is true however that method injection allows you to preconfigure the bean that you inject. So it's probably just the way it should be. Method injection does allow a huge amount of flexibility and choice in the spirit of Spring. Thanks for your help all.

                  Comment


                  • #10
                    Originally posted by Narada View Post
                    In the case of prototype inside singleton what you would intuitively expect to work doesn't work although I'm sure there are those that argue that it behaves exactly as you would expect. I'm not sure if it is possible to somehow have Spring implicitly do what method injection does when it encounters this kind of setup.
                    Couldn't you mark the prototype as a scoped-proxy?
                    http://www.springframework.org/docs/...ther-injection

                    Comment

                    Working...
                    X