Question

We have a web application that uses Spring (3.0.5) and CXF (currently 2.4.2 for various reasons but upgrading is an option if that makes any difference) and is deployed on Tomcat.

The application is initialized using the org.springframework.web.context.ContextLoaderListener.

Starting and shutting the application down works like a charm but if I try to refresh the Spring application context, using

((ConfigurableApplicationContext)applicationContext).refresh();

I run into problems. The application context first destroys all its beans (including CXFBusImpl, or rather its subclass SpringBus). SpringBus however calls close() on its application context – leading to a NullPointerException when the application context shortly after tries to close its bean factory:

java.lang.NullPointerException
    at org.springframework.context.support.AbstractRefreshableApplicationContext.closeBeanFactory(AbstractRefreshableApplicationContext.java:152)
    at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:124)
    at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:467)
    at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:397)

Is there anything I can do to avoid this (other than modifying CXF)? If I skip CXF everything works.

Answer 1

I don’t think you can tell CXF not to work that way. What you could do though is to isolate the parts of your application that need restarting into their own context that you build and and tear down as you choose without involving the main context over much. Perhaps you’d do that with a ClassPathXmlApplicationContext, though there are a few choices. I think you’ll be setting the outer context as the parent of the inner, and referring to outer beans with XML-config syntax like:

<ref parent="foo" />

You’ll then need to create some way of proxying the activity with CXF in the outer context to the beans in the inner context. This is the tricky part, as it is usually considered bad form for references to go that way round. You’ll probably have to have some kind of registry/proxy in the outer context that (relevant) inner beans connect to as part of their creation/init process (and deregister from at tear-down). You’ll also have to decide how to handle the case where a request needs to be served when there is no inner context. Tricky, especially if you want to do it elegantly…