On Sep 2, 2010, at 12:50 PM, Jarek Gawor wrote: > On Wed, Sep 1, 2010 at 4:52 PM, David Blevins <[email protected]> wrote: >> >> 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 :) >> > > I think we might have two different interpretations of what @DependsOn > annotation really means. For example, > > @Singleton > class A { > @PostConstruct > initA() { > } > } > > @Singleton @DependsOn("A") > class B { > } > > My understanding of the @DependsOn is that before bean B is > instantiated, the container must ensure that bean A is fully > initialized (the A.initA() post-construct method is called). And since > B can be initialized lazily the container has to enforce the > @DependsOn at runtime.
Checked the spec and it looks like my interpretation during the EJB discussions is not what we ended up with spec wise. Go ahead with the patch. There's a small tweak I'd like to make so that we don't expose a 'getInstance' method from the SingletonContainer, but that's minor. -David
