On Wed, Sep 1, 2010 at 3:15 PM, David Blevins <[email protected]> wrote: > > 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. >
Calling deploy (and start now) in the right @DependsOn order doesn't mean an actual bean instance will be created. Not for singleton beans. If every singleton bean had @Startup the order of deploy calls would be sufficient. But you can have singleton beans without @Startup but with @DependsOn. So @DependsOn initialization needs to be followed however and whenever the bean is actually started. For stateless beans, calling deploy (and start) in the right @DependsOn order is sufficient because the beans are always instantiated (and put into a pool). It's almost like all stateless beans are annotated with @Startup. Jarek
