Currently, the spec does not forbid the field access strategy to be used for normal-scoped CDI beans (i.e. injected instances managed by the CDI container). However, this doesn't work because injectable references for normal-scoped beans are client proxies and not direct references to contextual instances (see also "6.5.3. Contextual reference for a bean" [1] and "5.4. Client proxies" [2]). The only solution would be to detect a client proxy and when encountered, use the underlying instance instead of attempting to validate the proxy object. Unfortunately, there is no portable way to detect and unwrap the client proxy. Moreover, there is no way in Java to delegate field access to the underlying instance - public fields are not allowed on normal-scoped CDI beans. So I would consider limiting support for validation of normal-scoped CDI beans. A note or a new entry in the FAQ might be enough.

[1]
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#contextual_reference
[2]
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#client_proxies

I am not exactly following you. What exactly is not working in practice with Bean Validation + CDI in your opinion?
All BV implementations have provisions to work with Weld and its proxy based approach. We have been discussing it with the various implementors (there was a Bean Validation issue discussing this).

Hi Emmanuel,

if you have a normal-scoped bean with a field annotated with e.g. @NotNull (i.e. the field access strategy is used) the validation of an injected bean instance will always fail because proxy fields are never initialized. I've discovered this when working on [1]. On the other hand, if you annotate a method (property access strategy is used) Weld delegates to the underlying instance (i.e. appropriate getter is called).

Thanks,
Martin

[1]
http://lists.jboss.org/pipermail/weld-dev/2015-May/003335.html

Then I think you are talking about the problem I mentioned.
Check out the conversation here https://hibernate.atlassian.net/browse/BVTCK-69

I don't think this is exactly the same problem. BVTCK-69 is mainly talking about the workaround for javax.validation.Valid applied to a method. This use case is about having a normal-scoped bean with a field to be validated. So if you validate a client proxy (implemented as a subclass in Weld) the field access strategy simply does not work (proxy fields are never initialized).

Ok, that's a similar idea though. Let me discuss a but with Hardy and Gunnar.