Eu tenho um cenário configurando o Spring Security no Jetty incorporado que parece estar um pouco resolvido se eu usar o JavaConfig para configurar o servidor Jett

Como resultado, parece que JavaConfig, em vez de XML, pode ser a melhor opção para grandes partes do projeto. No entanto, existem alguns detalhes nos namespaces XML, como<context:component-scan /> que não estão prontamente disponíveis em um@Configuration configuração

Eu descobri queApplicationContextAware é homenageado por@Configuration classes, portanto é possível o seguinte

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

A alternativa, que é documentado, é ter o@Configurationlasse @ use um@ImportResource anotação e extraia um arquivo XML existente:

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

Acho que a pergunta é "É uma má forma abusarApplicationContextAware dessa maneira, ou realmente não é abuso "? Alguma coisa parece estranhamente suja sobre a abordagem, então eu não ficaria surpreso se os caras da Spring tivessem coberto isso de uma maneira ou de outra que eu não tenha visto.

Para os interessados, o problema está relacionado à digitalização de uma configuração de Jersey com@Resource e@Providerlasses que eu preferiria não precisar gerenciar manualmente as entradas em uma configuração de classe / XM