How can getReference() legally be invoked during AfterDeploymentValidation event if contexts have not been created yet?

[ljnelson]

Section 11.5.4 says:

The container must fire an event after it has validated that there are no deployment problems and before creating contexts or processing requests [emphasis mine].

Section 11.3 indicates that it is legal to call BeanManager#getReference(Bean, Type, CreationalContext) in an AfterDeploymentValidation observer method.

In order to get contextual references, such as those returned by getReference(), you need a context.

Is this a bug in the specification? Does section 11.5.4 need to be amended in some way?

[mkouba]

Well, the fact that the AfterDeploymentValidation event must be fired before the contexts are created does not imply that the contexts must be created after all AfterDeploymentValidation observers are notified. For example, a context could be created/initialized lazily, once needed, therefore when calling BeanManager#getReference() inside an AfterDeploymentValidation observer method.

However, I think that the wording in section 11.3. could be relaxed a bit - I don't think the "before creating contex" part makes sense.

[manovotn]

So, the bean validation actually happens before your AfterDeploymentValidation listeners get notified. This fulfills what Section 11.5.4 says and after that, you are free to create new beans (as per Section 11.3) inside that listener. The specification puts no restrictions on whether contexts need to be created eagerly or lazily.

You can take a look at how Weld does it here - it shows the flow I just described.

However, I think that the wording in section 11.3. could be relaxed a bit - I don't think the "before creating contex" part makes sense.

I agree it's not overly useful, but it is probably the only point which implies the earliest point at which contexts can be created?

[ljnelson]

However, I think that the wording in section 11.3. could be relaxed a bit - I don't think the "before creating contex" part makes sense.

I agree. If I remember my history right, there was a time when getReference() was forbidden in here somewhere, and then those restrictions were relaxed. The language looks like it just got left over. Clearly you can call getReference(), which means that contexts must be available (lazy or no) so we should probably just lose this language.

[manovotn]

If I remember my history right, there was a time when getReference() was forbidden in here somewhere

Well that's still there (11.3.), spec says that if you call BM.getReference() prior to ABV, you get an exception.

[ljnelson]

If I remember my history right, there was a time when getReference() was forbidden in here somewhere

Well that's still there (11.3.), spec says that if you call BM.getReference() prior to ABV, you get an exception.

No, I know that, I meant at some point in the long-ago past I seem to recall you couldn't even call it at AfterDeploymentValidation time.

[manovotn]

Oh, I see.

[ljnelson]

Ah; may have found it: https://issues.redhat.com/browse/CDI-392

[ljnelson]

Not quite the right issue but in the general vicinity. Too lazy to dig further. 😄

[manovotn]

This issue is long overdue but still valid for CDI 4.0 - https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#after_deployment_validation
Will add it to the tracking issue for next version, see #622