On Sep 1, 2010, at 8:01 AM, Jarek Gawor wrote: > 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.
Cool. Still we shouldn't need either because the existing @DependsOn code does fully take care of ensuring both those things. We do a graph sort of all the beans and sort them by their @DependsOn information and call deploy on everything in the right order which ensures everything you need is there before you start. We also check that everything you reference in @DependsOn is in your application, so it isn't possible for start to reach you and your dependency not be there. Now with the start() method, we still have that but a little extra insurance for beans that reference each other and don't use @DependsOn -- they could still work provided they don't cyclicly invoke each other in PostConstruct/PreDestroy. -David
