On Wed, Sep 1, 2010 at 2:11 AM, David Blevins <[email protected]> wrote: > > Note the 'initializeDependencies' method of the SingletonInstanceManager > shouldn't be necessary. The CheckDependsOn validation code should pick up > that scenario where a @DependsOn points to a non-existent bean. There's a > related CheckDependsOnTest that tests it. The > 'createInstance(dependencyInfo)' call happens automatically when anyone > invokes a singleton via it's proxy, so we should be good there and can let > the createInstance calls happen naturally as part of usage. Technically, > that would also cause a bug as the code that actually enforces the concept of > the singleton is in the 'getInstance' method, calling 'createInstance' > directly will bypass that can cause an instance to be created and immediately > forgotten -- i.e. it doesn't stick unless called by 'getInstance'. We could > definitely document that better. Feel free to throw some javadoc in if > you're feeling ambitious :) >
The initializeDependencies method is there to ensure the beans specified via @DependsOn are actually initialized before the bean with @DependsOn is initialized. It is not about checking for non-existed beans. A singleton bean can be initialized eagerly or lazily and this method ensures that however the bean is initialized, its dependencies via @DependsOn are are initialized beforehand. As to createInstance() thing, this might be a bit hard to see in the patch but initializeDependencies() calls SingletonContainer.createInstance() which calls SingletonInstanceManager.getInstance(). So the instances should definitely not be forgotten. Thanks a lot for your comments. Jarek
