On Sep 1, 2010, at 12:48 PM, Jarek Gawor wrote: > 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.
Right, a n...@startup bean is a lazy reference that will be initialized on first use using the same code you have in that block. We can certainly have an option to eagerly start them, but effectively they are the same. The n...@startup beans will all effectively start in the order they are used by the @Startup bean that depends on them. We can certainly have a flag to configure either behavior; lazy semantics or eager semantics. Both will work. Anyway, the overall change is great. The more I think about the separate startup phase the more I like it. It occurs to me while chatting about all this that the @Asynchronous support essentially means that startups can be multithreaded events. Having a separate deploy/start phase where beans are fully "ready" in the deploy phase but not executing till the start phase is only going to increase the sanity in that scenario :) -David
