Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-11373

Module configurer changes required to have both the module spring MVC and the module services in the same context

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.4
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-5098Create krms module configuration
      KULRICE-3973Spring 3.0.1 and module beans
      KULRICE-9889Move deprecated data code and services to the rice-kns module
      KULRICE-6599Module names passed to module configurers should all be lowercase
      KULRICE-8428Improved support for KRAD modules
      KULRICE-180Revisit Spring configuration and service locators
      KULRICE-4987Change name of "shareddata" module to "location"
      KULRICE-4529Split out service apis out into their own maven module in the Rice project
      KULRICE-5638Figure out how to make caching possible for services in the core module
      KULRICE-2177Consolidate all Rice Struts modules into a single struts module
    • Epic Link:
    • Rice Module:
      KRAD
    • Application Requirement:
      KC
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      During the preparation for the KC move to KRAD, we made the decision that we want our spring MVC context for a module in the same context as the module services since the controller for a particular module would make heavy use of the services in the module. One of the major advantages of moving from struts to spring MVC is so you can inject services into the controllers and we would like to fully utilize this feature without having to import all of the service beans into the MVC context again. Doug from KC did some analysis on how this can be best achieved to suit our needs (https://wiki.kuali.org/display/KRACOEUS/Spring+MVC+and+Rice+ModuleConfigurer).

      To put in a nutshell, the way we have chosen to proceed with this is to use the module configurer pick up our spring controller context which will then let the controllers have access to all the module related services as well as the DD files. This requires the following minor changes to the module configurer.

      1. Move the createRootRiceResourceLoader code to its own protected method so we can override.

      Index: rice-middleware/core/framework/src/main/java/org/kuali/rice/core/framework/config/module/ModuleConfigurer.java
      ===================================================================
      --- rice-middleware/core/framework/src/main/java/org/kuali/rice/core/framework/config/module/ModuleConfigurer.java  (revision 43187)
      +++ rice-middleware/core/framework/src/main/java/org/kuali/rice/core/framework/config/module/ModuleConfigurer.java  (working copy)
      @@ -306,8 +306,7 @@
              }
               
              if (!files.isEmpty()) {
      -           ResourceLoader rl = RiceResourceLoaderFactory.createRootRiceResourceLoader(servletContext, files,
      -                    getModuleName());
      +           ResourceLoader rl = createResourceLoader(servletContext, files, getModuleName());
                  rl.start();
                  GlobalResourceLoader.addResourceLoader(rl);
              }
      @@ -319,6 +318,11 @@
              }
          }
           
      +   protected ResourceLoader createResourceLoader(ServletContext servletContext, List<String> files, String moduleName) {
      +       return RiceResourceLoaderFactory.createRootRiceResourceLoader(servletContext, files,
      +        moduleName);
      +   }
      +   
      

      2. provide a protected method so we can access the servlet context like this

      ModuleConfigurer.java
        
         protected ServletContext getServletContext() {
             return servletContext;
         }
      

      In addition to the above, it would be great if the parseFileList method in the module configurer can be made protected as opposed to private so we can easily override that in KC, hence providing overriding mechanisms for our implementers just like rice does.

      ModuleConfigurer.java
      -   private List<String> parseFileList(String files) {
      +   protected List<String> parseFileList(String files) {
      

        Issue Links

          Activity

          Hide
          Douglas Pace added a comment -

          Jerry -

          The additional changes require Servlet Spec 3.0 which means deprecating Tomcat 6 support. We are currently asking our Tech Subcommittee for permission to do that but I'm not sure if Rice would want to do that as well. Here are the additional changes that are required if you want to review them and let us know what you think.

              @Override
              protected ResourceLoader createResourceLoader(ServletContext servletContext, List<String> files, String moduleName) {
                  BaseResourceLoader rl = (BaseResourceLoader) RiceResourceLoaderFactory.createRootRiceResourceLoader(servletContext, files, getModuleName());
                  rootResourceLoader = rl;
                  return rl;
              }
              
              @Override
              protected void doAdditionalModuleStartLogic() throws Exception {
                  DispatcherServlet loaderServlet = new DispatcherServlet((WebApplicationContext) ((SpringResourceLoader) rootResourceLoader.getResourceLoaders().get(0)).getContext());
                  ServletRegistration registration = getServletContext().addServlet(dispatchServletName, loaderServlet);
                  registration.addMapping("/" + dispatchServletName + "/*");
                  for (String filterName : filtersToMap) {
                      FilterRegistration filter = getServletContext().getFilterRegistration(filterName);
                      filter.addMappingForServletNames(null, true, dispatchServletName);
                  }
              }
          
          Show
          Douglas Pace added a comment - Jerry - The additional changes require Servlet Spec 3.0 which means deprecating Tomcat 6 support. We are currently asking our Tech Subcommittee for permission to do that but I'm not sure if Rice would want to do that as well. Here are the additional changes that are required if you want to review them and let us know what you think. @Override protected ResourceLoader createResourceLoader(ServletContext servletContext, List< String > files, String moduleName) { BaseResourceLoader rl = (BaseResourceLoader) RiceResourceLoaderFactory.createRootRiceResourceLoader(servletContext, files, getModuleName()); rootResourceLoader = rl; return rl; } @Override protected void doAdditionalModuleStartLogic() throws Exception { DispatcherServlet loaderServlet = new DispatcherServlet((WebApplicationContext) ((SpringResourceLoader) rootResourceLoader.getResourceLoaders().get(0)).getContext()); ServletRegistration registration = getServletContext().addServlet(dispatchServletName, loaderServlet); registration.addMapping( "/" + dispatchServletName + "/*" ); for ( String filterName : filtersToMap) { FilterRegistration filter = getServletContext().getFilterRegistration(filterName); filter.addMappingForServletNames( null , true , dispatchServletName); } }
          Hide
          Gayathri Athreya added a comment - - edited

          Jerry, our technical subcommittee has approved removing Tomcat6 support for KC 6.0, which means we can add the above code that requires Servlet 3.0 to our code base. If Rice plans to continue Tomcat 6.0 support, then we should probably not move the above code to the base module configurer. If you agree, let us know and we will commit the changes we initially proposed.

          Show
          Gayathri Athreya added a comment - - edited Jerry, our technical subcommittee has approved removing Tomcat6 support for KC 6.0, which means we can add the above code that requires Servlet 3.0 to our code base. If Rice plans to continue Tomcat 6.0 support, then we should probably not move the above code to the base module configurer. If you agree, let us know and we will commit the changes we initially proposed.
          Hide
          Gayathri Athreya added a comment -

          Jerry, I am going to only commit the changes you approved and are listed in the jira description for now. I can commit the servlet 3.0 code later if you decide you want it in Rice.

          Show
          Gayathri Athreya added a comment - Jerry, I am going to only commit the changes you approved and are listed in the jira description for now. I can commit the servlet 3.0 code later if you decide you want it in Rice.
          Hide
          Jerry Neal (Inactive) added a comment -

          Thanks Gayathri. I will review this with the Rice team

          Show
          Jerry Neal (Inactive) added a comment - Thanks Gayathri. I will review this with the Rice team
          Hide
          Gayathri Athreya added a comment -

          Our needs have been met with these changes. If we need to commit anything else like the servlet 3.0 code, we can do that as part of another jira, please let us know.

          Show
          Gayathri Athreya added a comment - Our needs have been met with these changes. If we need to commit anything else like the servlet 3.0 code, we can do that as part of another jira, please let us know.

            People

            • Assignee:
              Gayathri Athreya
              Reporter:
              Gayathri Athreya
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel