Hi all,
I would not like to add an XML "bloated" mechanism as part of CDI 2.0. Spontaneously I would propose a more CDI like things like:
- Adding a @Configured annotation (basically a qualifier). This can be in addition to @Inject and would allow to inject "configured" values.
- Since configuration can change we may think of a (CDI) event/reinject mechanism based on config changes. By default, this is switched off and we can discuss how it would be activated, e.g. by an additional flag settable with the @Configured annotation, or an additional @Observable ConfigChangeEvent (similar to the Griffon framework), or both.
- Hereby configured values theoretically behave similar as all other injection points. They also can be qualified (the aspect of scopes, I did not yet have time to think about). The only difference is, that they are satisified using the configuration "system".
- The configuration "source" itself could in the extreme simplest way be a Provider<Map<String,String>>. The CDI spec should not care about how this map is provided (XML, DB, overrides, etc). This still can be standardized later. As long as the ConfigurationSource SPI is defined, companies still can hook in the logic and level of configuration abstraction they need.
- Of course, since not only Strings can be injected, we need some conversion or adapter logic as basically outlined in my blog. Also here we can add a simple SPI and let the details to the RI.
Summarizing a
- @Configured annotation
- some kind of change event
- a ConfigurationSource extends Provider<MapString,String>>
- a conversion mechanism from String to T.
we get a full fledged configuration mechanism that leverages CDI.
That would be my idea basically. WDYT? I will try to work that out in more details. Basically it should be implementable even with the CDI mechanism already in place with CDI 1.1.
Best,
Anatole