AbstractSecurityWebApplicationInitializer funktioniert nicht

Question

Ich habe versucht, Webapp in Java-Konfiguration zu laden. In RAFTWebAppInitializer habe ich zuerst die Config-Klassen zusammen mit dem selbst entwickelten Framework registriert. Aber Federsicherheitsfilterkette wirft Fehler.

Andere als diese haben wir die Konfigurationsklasse für Servlet DispatcherConfiguration.class. Aber ich bekomme immer den Fehler 2016-04-01 14: 05: 37,237 INFO [localhost-startStop-1] context.ContextLoader (ContextLoader.java:347) - Root WebApplicationContext: Initialisierung in 0 ms abgeschlossen 2016-04- 01 14: 05: 37,237 DEBUG [localhost-startStop-1] filter.GenericFilterBean (GenericFilterBean.java:177) - Initialisierungsfilter 'springSecurityFilterChain' 01-Apr-2016 14: 05: 37.252 SEVERE [localhost-startStop-1] org .apache.catalina.core.StandardContext.startInternal Ein oder mehrere Filter konnten nicht gestartet werden. Vollständige Details finden Sie in der entsprechenden Container-Protokolldatei 2016-04-01 14: 05: 37,252 INFO [localhost-startStop-1] support.AbstractApplicationContext (AbstractApplicationContext.java:957) - Schließen von Root WebApplicationContext: Startdatum [Fr Apr 01 14:05:35 EDT 2016]; Wurzel Kontexthierarchie

Und in Behälter log, 01-Apr-2016 12: 06: 17,359 severe [localhost-Start-Stopp-1] org.apache.catalina.core.StandardContext.listenerStart Exception Senden Kontext initialisiert Ereignis Hörer Instanz der Klasse org.springframework.web.context.ContextLoaderListener org.springframework.beans.factory.BeanCreationException: Fehler beim Erstellen der Bean mit dem Namen 'chassisConfig': Instanziierung der Bean fehlgeschlagen; Verschachtelte Ausnahme ist org.springframework.beans.BeanInstantiationException: Instantiiert [com.capitalone.raft.refapps.api.mvc.config.ChassisConfig $$ EnhancerBySpringCGLIB $$ 7e8af6fb] fehlgeschlagen: Kein Standardkonstruktor gefunden; nested Ausnahme ist java.lang.NoSuchMethodException: com.capitalone.raft.refapps.api.mvc.config.ChassisConfig $$ EnhancerBySpringCGLIB $$ 7e8af6fb() bei org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean (AbstractAutowireCapableBeanFactory. .java-: 1105) bei org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance (AbstractAutowireCapableBeanFactory.java:1050) bei org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean (AbstractAutowireCapableBeanFactory.java:510) bei org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean (AbstractAutowireCapableBeanFactory.java:482) bei org.springframework.beans.factory.support.AbstractBeanFactory $ 1.getObject (AbstractBeanFactory.java306) bei org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton (DefaultSingletonBeanRegistry.java:230) bei org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean (AbstractBeanFactory.java:302)

Nicht in der Lage zu understans, denn wenn ich das Debuggen des Server-Initialisierung gehen, tatsächlich sind diese beiden Methoden genannt:

@Override public final Leere onStartup (ServletContext ServletContext) wirft ServletException { if (enableHttpSessionEventPublisher()) { servletContext.addListener (HttpSessionEventPublisher.Klasse); } insertSpringSecurityFilterChain (servletContext); afterSpringSecurityFilterChain (servletContext); } dann

private void insertSpringSecurityFilterChain (ServletContext ServletContext) { String filter = "springSecurityFilterChain"; DelegatingFilterProxy springSecurityFilterChain = new DelegatingFilterProxy (filterName); Zeichenfolge contextAttribute = getWebApplicationContextAttribute(); if (contextAttribute! = Null) { springSecurityFilterChain.setContextAttribute (contextAttribute); } registerFilter (servletContext, true, filterName, springSecurityFilterChain); }

Answer 1

Da ich die Kontextklasse mit unserem homegrown Framework bootstrappte, musste ich den Kontext manuell aktualisieren. Nach der Aktualisierung wurde das Problem behoben. Aber eines muss man sich merken, wenn man den Komponenten-Scan verwendet und versucht, es auf Root-Ebene zu setzen. Aber wir müssen vielleicht die Konsequenzen verstehen. Irgendwann beim Scannen des Root-Pakets versucht es möglicherweise, zusätzliche (oder nicht mit einem bestimmten Kontext zusammenhängende) Klassen zu registrieren, die zu Konflikten führen können. Aktualisierter Code:

public class RAFTWebAppInitializer extends AbstractAnnotationConfigDispatcherServletInitializer { 
    public static final String SPRING_DISPATCHER_SERVLET_NAME = "raft"; 
    public static final String URL_PATTERN = "/"; 
    private static final String SPRING_FILTER_CHAIN_NAME = "springSecurityFilterChain"; 
    private static final String UNABLE_TO_REGISTER_FILTER_CHAIN = "Unable to register filter chain"; 


    private Logger logger = LogManager.getLogger(RAFTWebAppInitializer.class); 
    @Override 
    protected WebApplicationContext createRootApplicationContext() { 
     //initialize and register context 
     AnnotationConfigWebApplicationContext rootAppContext = new AnnotationConfigWebApplicationContext(); 
     logger.info("Entering in root context to register abc library"); 
     /*Home grown framework */ 
     ABCInitializer abcInitializer = new ABCInitializer(); 
     abcInitializer .initialize(rootAppContext); 
     logger.info("Exiting after registering chassis library"); 

     rootAppContext.register(getRootConfigClasses());  
     logger.info("Exiting after registering App config classes");   
     rootAppContext.refresh(); 

     return rootAppContext; 
     }