Allow the use of custom PropertySource annotations in @Configuration classes [SPR-8963]

[spring-projects-issues]

Daniel Fernández opened SPR-8963 and commented

IMHO, there is a mismatch between the configuration possibilities offered by XML and @Configuration classes in Spring 3.1, which could be fixed by allowing developers to create custom annotations that could be used in @Configuration classes (in the same way as @PropertySource) for performing pre-configured infrastructure tasks.

These annotations could perform these configuration tasks "underneath", hiding their complexities to Spring users, in the same way namespace handlers can in an XML file.

@PropertySource is the clear example to this, as it registers a PropertySource for the specified ".properties" files, but the object registered is of a specific class hard-coded into Spring's code. This avoids the possibility of creating instances of other implementations of the PropertySource interface that perform more complex processing of .properties entries.

Specifically, the jasypt project [ http://www.jasypt.org ] --of which I'm author-- defines an "encryption" XML namespace which allows developers to register an EncryptablePropertySource that performs automatic transparent decryption of properties with "encryption:encryptable-property-placeholder/", which works in a way equivalent to "context:property-placeholder/", but applying transparent decryption.

I would love to be able to offer this same easiness of configuration in @Configuration classes with an @EncryptablePropertySource annotation, but as it happens this is not possible :-(

Please, extend the @Configuration mechanism for allowing custom annotations (with their associated handlers).

Thanks.

---

Affects: 3.1 GA

Reference URL: http://forum.springsource.org/showthread.php?120147-Can-I-create-my-own-annotations-for-enabling-features-at-Configuration-classes

Issue Links:

• Improve @PropertySource loading support [SPR-12116] #16732 Improve @PropertySource loading support ("is duplicated by")
• Allow @PropertySource to be specified on a test class [SPR-10232] #14865 Allow @PropertySource to be specified on a test class
• Support declarative PropertySource annotations in the TestContext framework [SPR-11377] #16004 Support declarative PropertySource annotations in the TestContext framework
• SEC-3123 Encrypted property value support
• Add support for UTF-8 and other charset/encoding to @PropertySource [SPR-13874] #18447 Add support for UTF-8 and other charset/encoding to @PropertySource
• convertPropertyValue (for reading encrypted values) not working [SPR-14001] #18574 convertPropertyValue (for reading encrypted values) not working
• Custom @Profile annotations not working on @Configuration classes [SPR-11808] #16428 Custom @Profile annotations not working on @Configuration classes
• PropertySourcesPlaceholderConfigurer never calls "convertProperties" on merged properties [SPR-8928] #13568 PropertySourcesPlaceholderConfigurer never calls "convertProperties" on merged properties
• Add encryption support for PropertyPlaceholderConfigurer [SPR-10666] #15294 Add encryption support for PropertyPlaceholderConfigurer
• Backport encrypted property functionality from spring-cloud-config environment work [SPR-12635] #17236 Backport encrypted property functionality from spring-cloud-config environment work
• Allow a single element to override an array attribute in a meta-annotation [SPR-13972] #18544 Allow a single element to override an array attribute in a meta-annotation

Referenced from: commits a378912

5 votes, 12 watchers

[spring-projects-issues]

Bjorn Harvold commented

Definitely would make my life easier

[spring-projects-issues]

Sam Brannen commented

We could introduce a PropertySourceResolver interface that can be configured via a resolver attribute in @PropertySource annotation (similar to how @ActiveProfiles supports an ActiveProfilesResolver). If such a resolver were introduced, you could then use @PropertySource as a meta-annotation on your custom composed @EncryptablePropertySource annotation.

Does that sound like what you're looking for?

[spring-projects-issues]

Daniel Fernández commented

Would that mean that I'd have to provide an implementation of that PropertySourceResolver interface, or would a default implementation already exist that looks for all the annotations meta-annotated with @PropertySource?

[spring-projects-issues]

Sam Brannen commented

Would that mean that I'd have to provide an implementation of that PropertySourceResolver interface, or would a default implementation already exist that looks for all the annotations meta-annotated with @PropertySource?

Yes, if we introduce a PropertySourceResolver SPI you would have to provide an implementation that registers EncryptablePropertySource instances instead of ResourcePropertySource instances (which is what Spring registers behind the scenes for @PropertySource).

[spring-projects-issues]

Sam Brannen commented

Please note that this is related to the following issues.

• SEC-3123
• PropertySourcesPlaceholderConfigurer never calls "convertProperties" on merged properties [SPR-8928] #13568
• Add encryption support for PropertyPlaceholderConfigurer [SPR-10666] #15294
• Backport encrypted property functionality from spring-cloud-config environment work [SPR-12635] #17236

[spring-projects-issues]

Juergen Hoeller commented

I've introduced a PropertySourceFactory strategy interface in core.io.support, with the following signature:

PropertySource<?> createPropertySource(String name, EncodedResource resource) throws IOException

The default implementation simply builds standard ResourcePropertySource wrappers.

@PropertySource allows for specifying factory=MyPropertySourceFactory.class now, in particular for meta-annotation purposes.

Juergen

[spring-projects-issues]

Marten Deinum commented

This would also fix #16732 which is more or less a duplicate of this one.