This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

AnnouncementAnnouncement Module

Collapse

No announcement yet.

Can I create my own annotations for enabling features at @Configuration classes?Page Title Module

Can I create my own annotations for enabling features at @Configuration classes?

Dec 15th, 2011, 06:26 AM

Hello,

The new annotations for @Configuration classes in Spring 3.1 are great, but I would like to extend one of them: @PropertySource, in order to add my own features to property processing...

Can this be done? Is there a way to create my own annotations so that they are executed at @Configuration classes and add my own features? This is something I obviously can do with XML, so I feel it should be possible with the new all-java system...

No, it is not currently possible to extend or customize @PropertySource. Feel free to create a JIRA improvement request for this, and please provide as much detail as possible about your use case.

If this is something that we see being common for folks, we'll look at opening it up. It could also be that there is just some missing functionality there that we can improve on in future releases...

Do keep in mind that @PropertySource is just a convenient declarative mechanism for registering PropertySource objects against the Environment. You can have complete control over this by using the Environment API. See the Javadoc for more details.

Comment

Thanks a lot for your answer Chris, I'll add this as a JIRA feature request for future Spring versions then.

I'll tell you my scenario:

I am the author of an encryption open source library called jasypt [http://www.jasypt.org], which provides some Spring-specific integration features.

In the upcoming 1.9.0 release, jasypt will provide an <encryption:*> Spring namespace for easily registering digesters and encryptors, and it will also include an <encryption:encryptable-property-placeholder> tag that will mimic the behaviour of <contextroperty-placeholder> but registering an extended version of PropertyPlaceholderConfigurer that will transparently decrypt entries in .properties files using a jasypt EncryptableProperties object (Spring 3.0) or an EncryptablePropertySource object (jasypt's implementation of PropertySource for Spring 3.1).

The problem is that, while with my <encryption:encryptable-property-source/> tag I can give Spring XML users the ability to easily register a PropertySource implementation that transparently decrypts .properties files, I cannot offer that to those users making use of the new @Configuration mechanism. Because @PropertySource registers a PropertySource of a specific hard-wired class that I cannot configure to be jasypt's EncryptablePropertySource.

For me it would be fantastic to be able to offer the same features using XML and using @Configuration... that's why I asked.