Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.3
    • Fix Version/s: 2.0.4
    • Component/s: Web
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      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.

        Activity

        Hide
        juergen.hoeller Juergen Hoeller added a comment -

        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

        Show
        juergen.hoeller Juergen Hoeller added a comment - 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
        Hide
        nebhale nebhale added a comment -

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

        Show
        nebhale nebhale added a comment - I'll give it a try today (as soon as I figure out how to get a handle to the Servlet inside an AppContext).
        Hide
        juergen.hoeller Juergen Hoeller added a comment -

        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

        Show
        juergen.hoeller Juergen Hoeller added a comment - 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
        Hide
        nebhale nebhale added a comment -

        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.

        Show
        nebhale nebhale added a comment - 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.
        Hide
        juergen.hoeller Juergen Hoeller added a comment -

        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

        Show
        juergen.hoeller Juergen Hoeller added a comment - 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

          People

          • Assignee:
            juergen.hoeller Juergen Hoeller
            Reporter:
            nebhale nebhale
            Last updater:
            Trevor Marshall
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              10 years, 44 weeks ago