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.
Jarek
