MP-Config 1.2.1: CDI injection questions

[Laird Nelson]

Hello; I had some questions from an implementor's perspective on the JSR 330 aspects of MicroProfile Config 1.2.1, specifically as they relate to CDI.

I see in both WildFly's and Open Liberty's implementations that injection of @ConfigProperty-annotated fields and parameters is handled by a Bean implementation that uses a Weld-specific, non-portable implementation trick to access the current InjectionPoint from the Bean#create(CreationalContext) method.  Part of the trick involves creating a fake InjectionPoint implementation that helps trick Weld, via its use of proxies, into handing you an InjectionPoint reference that reflects the actual InjectionPoint at which the return value of the Bean's create() method will be applied.  The other part of the trick appears to be having the bean say that it is handling ConfigProperty(name = "", defaultValue = "") injection points, which of course it is not doing—it is handling injection points annotated with specific instances of ConfigProperty (i.e. ones with "real" values for name and defaultValue, not empty Strings).

Here's WildFly's: https://github.com/wildfly-extras/wildfly-microprofile-config/blob/1.2.1/implementation/src/main/java/org/wildfly/microprofile/config/inject/ConfigInjectionBean.java#L93

Here's Open Liberty's: https://github.com/OpenLiberty/open-liberty/blob/r20171201-0700/dev/com.ibm.ws.microprofile.config.cdi/src/com/ibm/ws/microprofile/config/cdi/ConfigPropertyBean.java#L59

In each case, because the Bean being implemented is making use of this little trick, there must be some other magic going on, and I admit to being somewhat confused by it.  Specifically, the Bean being implemented reports its qualifiers as being equivalent to exactly:

@ConfigProperty(name = "", defaultValue = "")

Now, normally this would rule out injection points annotated with, say:

@ConfigProperty(name = "java.home", defaultValue = "No Home Found")

…because ConfigProperty#name() and ConfigProperty#defaultValue() are not annotated with @NonBinding.  So how does returning a ConfigProperty annotation literal with empty String values somehow "match" an injection point annotated with a ConfigProperty annotation with specific String values?  Normally this match wouldn't happen.  I suspect this is somehow also related to the Weld trick.

How does this work, exactly?

It most likely won't work for BeanManager#getReference or other mechanisms of programmatic lookup.  Is this OK with respect to the MicroProfile Config specification.  Is that OK?

The portable way to do this would result in the creation of potentially many Bean implementations.  Is that correct?

Best,

Laird

[Laird Nelson]

Also, where in the specification can I find the information about what default name I must use when, say, a field is annotated with simply @ConfigProperty (i.e. no name or defaultValue elements)?

[Arjan Tijms]

Hi Laird!

On Thursday, April 5, 2018 at 1:03:17 AM UTC+2, Laird Nelson wrote:

Hello; I had some questions from an implementor's perspective on the JSR 330 aspects of MicroProfile Config 1.2.1, specifically as they relate to CDI.

I see in both WildFly's and Open Liberty's implementations that injection of @ConfigProperty-annotated fields and parameters is handled by a Bean implementation that uses a Weld-specific, non-portable implementation trick to access the current InjectionPoint from the Bean#create(CreationalContext) method.  Part of the trick involves creating a fake InjectionPoint implementation that helps trick Weld, via its use of proxies, into handing you an InjectionPoint reference that reflects the actual InjectionPoint at which the return value of the Bean's create() method will be applied. 

Payara and OmniFaces use a similar trick, e.g. see

https://github.com/omnifaces/omnifaces/blob/3.x/src/main/java/org/omnifaces/util/BeansLocal.java#L257

and

https://github.com/omnifaces/omnifaces/blob/3.x/src/main/java/org/omnifaces/cdi/beans/InjectionPointGenerator.java#L22

I started a discussion about that quite a number of years ago, see http://lists.jboss.org/pipermail/cdi-dev/2014-November/005742.html

Until this day there's still no real solution for it, but the issue I created for it back then has been targeted for 2.1 now: https://issues.jboss.org/browse/CDI-610

The Payara/OmniFaces variant is not just a Weld trick btw. The same trick seems to work for OWB as well.

Kind regards,

Arjan Tijms

[Laird Nelson]

On Friday, April 6, 2018 at 11:26:31 AM UTC-4, Arjan Tijms wrote:

Hi Laird!

Hello!

 

Payara and OmniFaces use a similar trick, e.g. see

https://github.com/omnifaces/omnifaces/blob/3.x/src/main/java/org/omnifaces/util/BeansLocal.java#L257

OK.  I can wrap my head around this one, sort of—it says, basically, "Hey, BeanManager; get me a reference to the current InjectionPoint"—but the Open Liberty one seems to use another trick sort of "on top" of this: https://github.com/OpenLiberty/open-liberty/blob/r20171201-0700/dev/com.ibm.ws.microprofile.config.cdi/src/com/ibm/ws/microprofile/config/cdi/ConfigPropertyBean.java#L94-L102

Instead of simply asking the BeanManager to resolve an InjectionPoint reference, this seems to use a deliberately broken InjectionPoint implementation for some purpose (presumably because someone knows the only two methods that will actually be called from the implementation).  It's described here: https://github.com/OpenLiberty/open-liberty/blob/ce4fbba26ad0adc6514214be800ca7ce52c2bc0d/dev/com.ibm.ws.microprofile.config.cdi/src/com/ibm/ws/microprofile/config/cdi/DummyInjectionPoint.java#L25-L29

But I'm still hung up on how this particular ConfigPropertyBean gets selected for injection points annotated with a specific ConfigProperty annotation (i.e. one with non-default name and defaultValue elements).

Best,

Laird

[Laird Nelson]

On Friday, April 6, 2018 at 5:07:45 PM UTC-4, Laird Nelson wrote:

But I'm still hung up on how this particular ConfigPropertyBean gets selected for injection points annotated with a specific ConfigProperty annotation (i.e. one with non-default name and defaultValue elements).

Ah, I see partially now what was confusing me.

ConfigProperty's Javadoc does not show its elements as being annotated with Nonbinding, even though they are.  Or at least this particular expression of the API described by the specification annotates them that way.  :-)  Since the specification doesn't say anything about it :-) it's unclear to me whether Nonbinding can be assumed.  :-)

Best,

Laird