Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
0.6
-
None
-
None
Description
In deltapsike CDI configuration extension it is possible to add our own ConfigSourceProvider via the service loader mechanism.
Then when a property is searched from the @ConfigProperty annotation, the extension scans all ConfigSource loaded (according priorities defined as ConfigSource.ordinal attribute).
This mechanism works fine.
However it could be improved allowing users to target a specific ConfigSource for the searched property.
@Inject
@ConfigProperty(configSourceId="classpath" name = "property1")
private String property1;
Or an URI scheme could be used as follows:
@Inject
@ConfigProperty(name = "configSourceUriScheme://property1") //classpath://property1 for instance
private String property1;
Benefits would be to:
-enhance a lot readability / maintainability of the code
-enhance flexibility: allow a user to use a property name even it is already used elsewhere. (i.e. from a different ConfigSource)
-get rid of some tricky overriding if a property is accessible via several ConfigSource
e.g.: a framework should ensure no application deployed within will add ConfigSourceProvider/ConfigSource with a higher priority and the same property. One way to enforce this would be to implement another CDI extension checking the ConfigSource priorities.
It really sounds over complex and highlights the enhancement would be valuable.
For reference Spring proposes a mechanism not so far of the above and allowing enrichment by inheritance:
http://static.springsource.org/spring/docs/3.0.x/api/org/springframework/core/io/DefaultResourceLoader.html
Attachments
Issue Links
- is superceded by
-
CAMEL-5986 Property placeholders do not work for CDI injection
- Resolved