[#SPR-3297] Bean refresh in the DispatcherServlet

Spring Framework

Bean refresh in the DispatcherServlet

Created: 23/Mar/07 02:23 PM Updated: 03/Apr/07 07:22 AM

Component/s:

SpringWEB

Affects Version/s:

2.0.3

Fix Version/s:

2.0.4

Time Tracking:

Not Specified

Description

« Hide

When running a web application using Spring MVC, it's not possible to effectively refresh the web-tier application context. For example, when running a webflow application, the web-tier application context has a bean definition for a FlowRegistry. This registry reads a set of files from the filesystem based on wild-card patterns. If a new file is added, I'd like to read that file and use it without restarting the servlet. From a context perspective this is possible. A refresh of the context (via JMX for example) will reinstantiate the registry bean and read the new file in if it matches the selection pattern.

The problem lies in the DispatcherServlet. The DispatcherServlet maintains a cached reference to the HandlerMapping that it was started with. Therefore, even though the context has been refreshed and all beans recreated, the HandlerMapping is the original HandlerMapping bean and it may contain cached references to the original handlers and on through the object graph.

The DispatcherServlet should have a mechanism to reload HandlerMappings (or really any artifacts) from a refreshed web-tier application context.

All

Comments

Work Log

Change History

FishEye

Builds

Sort Order:

[ Permlink | « Hide ]

Juergen Hoeller added a comment - 27/Mar/07 04:30 PM

I've added a public "refresh()" operation with protected "onRefresh()" template method to FrameworkServlet/Portlet, and implemented "onRefresh()" accordingly in DispatcherServlet/Portlet. So if you call "refresh()" on the servlet instance, it should do a full refresh including a refresh of its strategy objects.

I'd appreciate if you give this a try in a 2.0.4 snapshot, Ben!

Juergen

[ Permlink | « Hide ]

Ben Hale added a comment - 28/Mar/07 08:29 AM

I'll give it a try today (as soon as I figure out how to get a handle to the Servlet inside an AppContext).

[ Permlink | « Hide ]

Juergen Hoeller added a comment - 28/Mar/07 08:39 AM

Ah, you're triggering this from within an app context? I rather expected that signal to come from the outside.

In that case, we might make the servlet listening to its context's ContextRefreshedEvent, as well as offering the public "refresh()" operation on the servlet. That would allow to trigger a full refresh through the app context's "refresh()" method as well.

Juergen

[ Permlink | « Hide ]

Ben Hale added a comment - 28/Mar/07 09:31 AM

Well, I'm willing to trigger the refresh externally (via JMX was my plan, but other possiblities too) but I'm not sure how to get a reference to the DispatcherServlet to call the refresh method.

That being said, I think that the additional ContextRefreshedEvent should be added as well. It's much easier to trigger it that way via JMX for sure, but both cases should be supported I think.

[ Permlink | « Hide ]

Juergen Hoeller added a comment - 03/Apr/07 07:22 AM

I've finally added the ContextRefreshedEvent support as well. DispatcherServlet/Portlet automatically refreshes its internal state if its ApplicationContext refreshes. So any bean which lives in the dispatcher's context may obtain a ConfigurableApplicationContext reference and call "refresh()" on it.

Juergen