Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Dec 27, 2011 · 7 comments
Assignees
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Dec 27, 2011

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:

  • #16732 Improve @PropertySource loading support ("is duplicated by")
  • #14865 Allow @PropertySource to be specified on a test class
  • #16004 Support declarative PropertySource annotations in the TestContext framework
  • SEC-3123 Encrypted property value support
  • #18447 Add support for UTF-8 and other charset/encoding to @PropertySource
  • #18574 convertPropertyValue (for reading encrypted values) not working
  • #16428 Custom @Profile annotations not working on @Configuration classes
  • #13568 PropertySourcesPlaceholderConfigurer never calls "convertProperties" on merged properties
  • #15294 Add encryption support for PropertyPlaceholderConfigurer
  • #17236 Backport encrypted property functionality from spring-cloud-config environment work
  • #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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 13, 2014

Bjorn Harvold commented

Definitely would make my life easier

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 22, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 22, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 13, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 14, 2015

Sam Brannen commented

Please note that this is related to the following issues.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Feb 22, 2016

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Feb 23, 2016

Marten Deinum commented

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants