We have an abstract base class for our tests that declares some common @ContextConfiguration. In some of the loaded context configurations we are using profiles (for example to switch between DB2 datasource and embedded derby datasource).
In our concrete test classes we extend the base class, and configure an @ContextHierarchy so the context of the base class acts as a parent application context. We want to be able to choose between DB2 and embedded derby on the concrete test class with @ActiveProfiles, but this seems to have no effect on the beans in the parent context. If we define the @ActiveProfiles on the parent, it is working.
Classes are not permitted to force their local configuration on parent classes. Doing so would essentially make it impossible for the parent class to serve as a superclass of more than one class... which would defeat the purpose of having a parent class to begin with.
As for an alternative approach, I can't think of anything off the top of my head that would allow you to use a class hierarchy to achieve this.
The straightforward (but not so pretty) approach would be to simply copy the parent config to the subclasses.
Using an ApplicationContextInitializer or an ActiveProfilesResolver might prove useful, but I'd have to investigate it further.
Let me know if any of these tips help you out. If not, I'll dig deeper at a later date.
Thanks for the quick feedback. I'll have a look at the ApplicationContextInitializer / ActiveProfilesResolver.
Note that the @ActiveProfilesdoes get applied to the configuration in the parent class if I don't use a @ContextHierarchy. But I want to use the hierarchy to take advantage of the application context caching. All tests with "default" profile can share the same cached parent context, and all tests with "embedded" profile can share another cached parent context.