There are several web resources out there that describe how to get a CDI bean (usually
ApplicationScoped) to be instantiated when the CDI container comes up. Here’s an arbitrarily selected one from Dan Allen:
Let’s look at the extension immediately above.
AfterDeploymentValidation event is the only event a portable extension can observe in a portable manner that indicates that the container is open for business. It is guaranteed to fire last in the dance that the container performs as it starts up.
In the extension above, then, you can see that it has saved off the beans it has discovered that have been annotated with a
Startup annotation (which isn’t defined in the gist, so it could be
javax.ejb.Startup or a
Startup annotation that Dan has defined himself). Then, for these beans, it uses the
getReference() method to get an actual Java object representing those beans.
So what’s the
toString() call for?
The short answer is: this is the only method that could conceivably cause the container-managed client proxy that is the object reference here to call the actual constructor of the actual underlying object that the user and everyone else is actually interested in.
If the bean has a normal scope [e.g. not
Singleton], then the contextual reference for the bean is a client proxy, as defined in Client proxies, created by the container, that implements the given bean type and all bean types of the bean which are Java interfaces.
OK, so whatever the
getReference() method returns is a client proxy. That means it’s going to forward any method invocation it receives to the object that it’s proxying (known as the bean’s contextual instance. CDI containers try to be efficient, so that object may not have been created yet—the proxy, in other words, might be lazy. So here, the contextual reference returned is a contextual reference (a client proxy) of type
Object, and the
toString() invocation causes the contextual reference (client proxy) to realize that oh, hey, the underlying contextual instance of whatever bean this is doesn’t yet exist, and to therefore invoke the “real” constructor, so that the “real” object (the contextual instance) can return something from its
As a happy side effect, the container is of course the one causing the instantiation of the “real” object, so it is going to perform dependency injection, invoke initializer methods, invoke any
PostConstruct-annotated methods, and so on. Presto: you have a portable way for your bean to be instantiated when the container comes up.
toString() in particular is used because there is a little nugget at the bottom of the Client Proxies section of the specification that says, innocuously (emphasis mine):
The behavior of all methods declared by
java.lang.Object, except for
toString(), is undefined for a client proxy. Portable applications should not invoke any method declared by
java.lang.Object, except for
toString(), on a client proxy.
File that one away: among other things that might mean don’t put your CDI-managed objects in
Collections, since doing so will use client proxy
So. If you’re feeling like this whole thing is a bit of a steaming hack—you call
toString(), and a whole lot of very sophisticated magic happens (!)—I can’t disagree.
Fortunately, there’s a better way.
Instead of the
toString() hack above, you can do the same thing in the extension in a more sanctioned, more explicit manner.
The first thing to understand is: who is doing the actual creation? If we can understand that, then we can understand how to do it eagerly and idiomatically.
The ultimate answer is: the bean itself, via the
create() method it implements from the
Contextual interface. So if you ever get a
Bean in your hand (or any other
Contextual), you can call
create() on it all day long and get new instances (this should sound scary, because it is). For example, suppose you have an
ApplicationScoped-annotated bean in your hand in the form of a
Bean object. If you call
create() on it three times, you will create three instances of this object, hopefully surprising and gently horrifying you. Those instances may be wrapped in proxies (for interception and such), but they won’t be wrapped in client proxies. Don’t do this!
Still, scary or not, we’ve found the method that some part of the container somewhere at some point will invoke when a contextual instance is needed (to further wrap in a contextual reference). But obviously when you inject an
ApplicationScoped-annotated bean into, say, three different locations in your code somewhere, everything behaves as though there’s only one instance, not three. So clearly the container is not running around rampantly calling
create() every time it needs an object. It’s acquiring them from somewhere, and having them created if necessary.
The container is actually calling a particular
get() method on the bean’s associated
Context, the machinery that implements its scope. This method’s contract basically says that the
Context implementation should decide whether to return an existing contextual instance, or a new one. So you can see that the
Context underlying application scope will (hopefully!) return the One True Instance™ of the bean in question, whereas the
Context implementation underlying some other scope may create new instances each time.
OK, so what do we know? Let’s step back.
- We know that a contextual reference is almost always a lazy client proxy, so merely obtaining one of these (via
getReference()method) is not enough (the existence of a client proxy says nothing about the existence of its underlying contextual instance). This is why Dan’s example invokes
toString()on the client proxy.
- We know how to talk to a
Contextand have it ensure that the right contextual instance (potentially newly-created) is returned if we ask for one. That is, we know that if we talk to it right, we won’t end up creating too many instances of a bean, thus disregarding its scope.
So to eagerly instantiate beans at startup while respecting their scopes, we should follow this approach in the extension as well—we’ll do basically what a lazy contextual reference (client proxy) does, in other words, when a
toString() method is invoked on it. We’ll need to effectively ask the right
Context for a contextual instance of the bean in question, creating it if necessary. This also would allow for custom-scoped beans to be instantiated eagerly, provided of course that the
Context backing the custom scope is actually active.
final Context context = beanManager.getContext(bean.getScope());
final CreationalContext<Object> cc = beanManager.createCreationalContext(bean);
Finally, we can ask the
Context for a contextual instance directly:
final Object contextualInstanceNotContextualReference = context.get(bean, cc);
So if you replace Dan’s line 19 above with these code snippets, you will eagerly instantiate beans at startup without relying on magic side effects.