Question

I have a scenario configuring Spring Security on embedded Jetty which seems to be somewhat solved if I make use of JavaConfig to configure the Jetty server.

As a result, it’s looking like JavaConfig rather than XML might be the better option for large chunks of the project. However, there are some niceties in the XML namespaces, like <context:component-scan /> which aren’t readily available in a @Configuration setting.

I have discovered that ApplicationContextAware is honored for @Configuration classes, so the following is possible

@Configuration
public class FooConfig implements ApplicationContextAware {
    @Override
    public void setApplicationContext(ApplicationContext applicationContext) {
        ((AnnotationConfigApplicationContext) applicationContext).scan("org.example");
    }
}

The alternative, which is documented, is to have the @Configuration class use an @ImportResource annotation and pull in an existing XML file:

@Configuration
@ImportResource("applicationContext-withComponentScan.xml")
public class BarConfig {}

I guess the question is “Is it bad form to abuse ApplicationContextAware in this way, or is it really not abuse”? Something just feels oddly dirty about the approach so I’d not be surprised if the Spring guys had covered this in some way or another that I’ve not spotted.

For the interested, the problem relates to scanning a Jersey setup with @Resource and @Provider classes that I’d rather not have to manually manage entries in a class/XML configuration.

Answer 1

Is it bad form to abuse ApplicationContextAware in this way, or is it really not abuse

Yes, this is bad form. If you’re going to fetch things out of the context manually, you may as well not bother with dependency injection in the first place.

However, your second option (@ImportResource("applicationContext-withComponentScan.xml")) is a good one – this is current best practice when you want to use these XML macros in combination with annotation-style config.

A third option is to use the current milestone build of Spring 3.1, which adds a way of doing these things all in Java, using @Feature. This is not yet production-ready, though.