1

I am trying to understand how Dependency Injection works. I am reading Pro Spring 2.5 and have gotten to chapter 3. Some questions that has come to my mind is:

When you make the bean factory in the main method of your stand alone application (it would be interesting to know in a web app too) and then read the bean configuration file, what happens then? Does it create the beans with their dependencies at that point and keeps those in a register or is it just the configuration information it keeps in the register?

I understand that you should try to keep dependency lookup to a minimum so if you have a MyApplication class or something that bootstraps the application that is preferred. Now, how would Spring or the POJO's know where and when to inject the dependencies if the factory with the register is only available in the main method? Isn't the register only available in the main method? Since you are not calling "getBean(...)" anymore where does the constructing take place? How does it manage to keep the beans as singletons etc?

LuckyLuke
  • 47,771
  • 85
  • 270
  • 434
  • Did you asked the same question 7 hours ago? http://stackoverflow.com/questions/9734483/how-is-dependency-injection-working – Ralph Mar 16 '12 at 16:35

2 Answers2

2

I think this would be best answered by reading the links posted here: What is dependency injection? Especially Martin Fowler's article.

Think of all your objects living inside a container. Objects inside this container have their entire life cycle (creation, destruction, initialisation) managed by spring or other objects inside the container. So when does class construction happen? Well, when you call getBean(), Spring will attempt to fetch this class instance for you. It will have certain dependencies (the spring-managed properties), so spring will construct instances of those classes too, who will also have other dependencies, and so on, recursively, until the relevant part of the object graph of your application is constructed.

When you shut down the container (the BeanFactory or ApplicationContext, spring then handles any shutdown necessary (i.e. destroying database connections etc.).

Singleton beans (beans for which only one instance will exist for the lifetime of the application) are pre-instantiated, but that is not a requirement. The entire object graph could be constructed lazily on-demand.

In web applications, something akin to a getBean() call happens to link a certain request to your controller, but the details vary between implementations. It's probably safe to assume this only happens once to bind every route to a controller.

Community
  • 1
  • 1
wds
  • 31,873
  • 11
  • 59
  • 84
  • Thanks that cleared some parts, however since you only invoke "getBean()" at the starting point how is Spring able to inject the right dependencies etc when the other classes never holds a reference to the factory? – LuckyLuke Mar 16 '12 at 17:55
  • Spring calls the constructor of those classes, they do not need a reference to the factory. – wds Mar 20 '12 at 10:14
  • Yes, thanks. I have understood the concept now and I see that I had misunderstood it completly at first:) – LuckyLuke Mar 20 '12 at 13:04
1

Does it create the beans with their dependencies at that point and keeps those in a register

Yes, by default once you create an instance of BeanFactory or ApplicationContext (see: BeanFactory vs ApplicationContext) Spring creates all beans and wires them up. The exception are beans with lazy scope, but if they are dependants of non-lazy beans, they will be created despite that.

Spring also manages correct order of bean initialization.

Now, how would Spring or the POJO's know where and when to inject the dependencies

Basically, all the beans live inside the Spring container. If you fetch one bean, it already has references to its direct dependencies. They in turns have dependencies to other. The bottom line is: all beans are typically created and wired up at startup and they are sort-of singletons.

See also

Community
  • 1
  • 1
Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
  • So what you are saying about how and when they get their dependencies is that MyApplication may have dependent of class A, which again has dependencies of B and C and so on? But I still don't understand the bean registery when you are using dependency injection instead of dependency lookup where you manually consult the bean factory and registery. How does each class obtain their dependencies? – LuckyLuke Mar 16 '12 at 17:06
  • @viper: how to explain this... Once you create your application context, all the beans are created and wired. Everything happens automatically and eagerly on startup. Spring will first create `B` and `C`, then create `A` and inject `B` and `C` into to. Finally it will create `MyApplication` and inject `C`. This is all done at startup and kept in memory. When you ask `BeanFactory` for `MyApplication` instance it simply returns already created bean with dependencies injected. Calling `getBean()` returns **already existing**, wired bean. – Tomasz Nurkiewicz Mar 16 '12 at 18:38
  • Do you have 5 minutes of spare time during the night to come on the Java chat? – LuckyLuke Mar 16 '12 at 18:41
  • @Viper, no unfortunately. But feel free to ask further question on SO, I/we will do our best to help you – Tomasz Nurkiewicz Mar 16 '12 at 18:58
  • So this happens at runtime? There is no lazy loading, the whole application (object graph) is in memory at once right after the MyApplication is looked up? It is done recursivly, plunging through the whole app at once? Maybe I start to understand. If it is done runtime is this opposed to what happens when you manually "new" up objects? – LuckyLuke Mar 16 '12 at 19:07
  • @Viper: yes! By default **all** beans are created and wired-up during `BeanFactory` initialization. When you call `getBean()` it simply returns an already created, initialized, wired and post-processed instance. There is no wiring past the initialization of application context. As eager as possible. (I am oversimplifying, there are non-singleton scopes, lazy beans and scoped proxies, etc. - by I am talking here about the defaults) – Tomasz Nurkiewicz Mar 16 '12 at 19:58
  • Okey, thank you:) Yet a case of where it seems to be more magic than it really is. – LuckyLuke Mar 16 '12 at 20:13