@Autowired in ServletContextListener

Question

i hava aclass InitApp

@Component
public class InitApp implements ServletContextListener {

@Autowired
ConfigrationService weatherConfService;

/** Creates a new instance of InitApp */
public InitApp() {
   }

public void contextInitialized(ServletContextEvent servletContextEvent) {
    System.out.println(weatherConfService);
   }
public void contextDestroyed(ServletContextEvent servletContextEvent) {
   }
}

and listener in web.xml:

    <listener>
        <listener-class>com.web.Utils.InitApp</listener-class>
    </listener>

    <listener>
      <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>

the confService print --> null what the problem?

Roselane

You should either define ConfigurationService in you xml Spring configuration, as Nambari pointed out, or you should put component-scan on a package that contains ConfigurationService and annotate the service with @Component or @Service – Finical

Answer 1

A couple of ideas came to me as I was having the same issue.

First one is to use Spring utils to retrieve the bean from the Spring context within the listener:

Ex:

@WebListener
public class CacheInitializationListener implements ServletContextListener {

    /**
     * Initialize the Cache Manager once the application has started
     */
    @Override
    public void contextInitialized(ServletContextEvent sce) {
        CacheManager cacheManager = WebApplicationContextUtils.getRequiredWebApplicationContext(
                sce.getServletContext()).getBean(CacheManager.class);
        try {
            cacheManager.init();
        } catch (Exception e) {
            // rethrow as a runtime exception
            throw new IllegalStateException(e);
        }
    }

    @Override
    public void contextDestroyed(ServletContextEvent sce) {
        // TODO Auto-generated method stub

    }
}

This works fine if you only have one or two beans. Otherwise it can get tedious. The other option is to explicitly call upon Spring's Autowire utilities:

@WebListener
public class CacheInitializationListener implements ServletContextListener {

    @Autowired
    private CacheManager cacheManager;

    /**
     * Initialize the Cache once the application has started
     */
    @Override
    public void contextInitialized(ServletContextEvent sce) {
        SpringBeanAutowiringSupport.processInjectionBasedOnCurrentContext(this);
        try {
            cacheManager.init();
        } catch (Exception e) {
            // rethrow as a runtime exception
            throw new IllegalStateException(e);
        }
    }

    @Override
    public void contextDestroyed(ServletContextEvent sce) {
        // TODO Auto-generated method stub

    }
}

The caveat in both these solutions, is that the Spring context must by loaded first before either of these can work. Given that there is no way to define the Listener order using @WebListener, ensure that the Spring ContextLoaderListener is defined in web.xml to force it to be loaded first (listeners defined in the web descriptor are loaded prior to those defined by annotation).

Madelinemadella

Answer 2

By declaring

<listener>
  <listener-class>com.web.Utils.InitApp</listener-class>
</listener>

in your web.xml, you're telling your container to initialize and register an instance of InitApp. As such, that object is not managed by Spring and you cannot @Autowired anything into it.

If your application context is set up to component-scan the com.web.Utils package, then you will have a InitApp bean that isn't registered as a Listener with the container. So even though your other bean will be @Autowired, the servlet container won't ever hit it.

That is the trade-off.

There are workarounds to this if you use programmatic configuration with a ServletContainerInitializer or a WebApplicationInitializer for servlet 3.0. You wouldn't use @Autowired, you would just have setter/getter that you would use to set the instance.

Here's an example

class SpringExample implements WebApplicationInitializer {
    @Override
    public void onStartup(ServletContext servletContext) throws ServletException {
        WebApplicationContext context = ...;

        SomeBean someBean = context.getBean(SomeBean.class);
        CustomListener listener = new CustomListener();
        listener.setSomeBean(someBean);

        // register the listener instance
        servletContext.addListener(listener);

        // then register DispatcherServlet and ContextLoaderListener, as appropriate
        ...
    }
}

class CustomListener implements ServletContextListener {
    private SomeBean someBean;

    public SomeBean getSomeBean() {
        return someBean;
    }

    public void setSomeBean(SomeBean someBean) {
        this.someBean = someBean;
    }

    @Override
    public void contextInitialized(ServletContextEvent sce) {
       // do something with someBean
    }

    @Override
    public void contextDestroyed(ServletContextEvent sce) {
    }
}

Note that Spring has some custom implementation of WebApplicationInitializer that are quite sophisticated. You really shouldn't need to implement it directly yourself. The idea remains the same, just deeper in the inheritance hierarchy.

Unamuno

Can you provide an example of a workaround? I am struggling to understand how the @Configuration bean would inject something into a bean that is managed by the container. How does the @Config bean get a reference to the container's bean? – Madelinemadella

@EricB. With a ServletContainerInitializer and a WebApplicationInitializer you are initializing and registering the ServletContextListener yourself. Since you also have access to the Spring WebApplicationContext(s), you can retrieve a bean from it and hand it to the listener. – Unamuno

@EricB. (If you want a full example, you'll have to give me until later.) – Unamuno

Sure - I can use something like WebApplicationContextUtils.getRequiredWebApplicationContext to retrieve the application context and then get the bean from that, but I wasn't sure if that is what you meant. I had understood from your post that it could be done via the Spring configuration class and push the spring bean into the listener (not have the listener pull the bean from the Spring context). – Madelinemadella

Ok - in that case, if you can give me an example of you idea when you have a minute, I would love to see how you can manipulate the listener bean from within Spring. – Madelinemadella

@EricB. It's up. It's very bare bones. And now that I think about it, getRequiredWebApplicationContext is probably better in almost all cases. It won't (always) work with other ServletContextListeners because you can't depend on the order of their initialization. – Unamuno

@eric Note that it isn't necessarily a bean. Though you could declare it within the Spring context and extract it. – Unamuno

Ahhh... now I see where you were going. I didn't realize that you wanted to programatically set the listener. I thought you were still using web.xml or @WebListener to declare the listener. Honestly, not a fan of either solution - this one buries the listener in the Spring code (hard to find/trace), and my solution makes the container dependent on knowing what Spring is doing, and requires ensuring that Spring has already initialized its context/beans prior to extracting the bean from the Spring context. – Madelinemadella

OVernight, just realized that I could also use SpringBeanAutowiringSupport to do this as well (see my posted answer). – Madelinemadella

Answer 3

@WebListener
public class StartupListener implements ServletContextListener {

    @Autowired
    private MyRepository repository;

    @Override
    public void contextDestroyed(ServletContextEvent event) {
    }

    @Override
    public void contextInitialized(ServletContextEvent event) {
        AutowireCapableBeanFactory autowireCapableBeanFactory = WebApplicationContextUtils.getRequiredWebApplicationContext(event.getServletContext()).getAutowireCapableBeanFactory();
        autowireCapableBeanFactory.autowireBean(this);

        repository.doSomething();
    }
}

Osteology

Answer 4

As others have said this listener observes by the web servlet(tomcat) context (Not the Spring Container) and is notified of servlet startup/shutdown.

Since it is created by the servlet outside of the Spring container it is not managed by Spring hence @Autowire members is not possible.

If you setup your bean as a managed @Component then Spring will create the instance and the listener wont register with the external servlet.

You cannot have it both ways..

One solution is the remove the Spring annotations and manually retrieve your member from the Spring Application context and set your members that way.

ie

    public class InitApp implements ServletContextListener {

        private ConfigrationService weatherConfService;

        private static ApplicationContext   applicationContext  = new ClassPathXmlApplicationContext("classpath:web-context.xml");

        @Override
        public void contextInitialized(ServletContextEvent servletContextEvent) {
            weatherConfService = applicationContext.getBean(ConfigrationService.class);
            System.out.println(weatherConfService);
        }

        @Override
        public void contextDestroyed(ServletContextEvent servletContextEvent) {
        }
    }

Ignatius

Answer 5

With current versions of Spring Boot 2, you can also register Servlets, filters, and listeners as Spring beans and use autowired components normally:

Registering Servlets, Filters, and Listeners as Spring Beans

Any Servlet, Filter, or servlet *Listener instance that is a Spring bean is registered with the embedded container. This can be particularly convenient if you want to refer to a value from your application.properties during configuration.

More info here Register @WebListeners in a way that allows them to register servlets and filters.

This means that you simply have to annotate your ServletContextListener as @Comonent.

Since Spring Boot 2.4 using @WebListener does not work anymore, mentioned in the release notes.

A side-effect of this change is that the Servlet container now creates the instance of the WebListener and, therefore, dependency injection such as with @Autowired can no longer be used. In such cases, @Component should be used instead.

Schmidt