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

Verify if these 1.0.3.2 fixes made it to 2.0 and if not, apply to 2.0 trunk

    Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-5124Tomcat 7 fixes for rice 2.0
      KULRICE-5448Apply these 1.0.3.3 fixes to Rice 2.0 code branch
      KULRICE-6897Rice 1.0.3.2 (KULRICE-5236) changes have not been merged into 2.0 codebase
      KULRICE-5110Merge 1.0.3.2 changesets to 2.0
      KULRICE-50721.0.3.2 fixes for Tomcat 7 support
      KULRICE-6038Update KSB documentation for changes made to KSB in 2.0
      KULRICE-5679Verify all source files include the ECL 2.0 header
      KULRICE-5126Convert bookstore sample application to rice 2.0
      KULRICE-6526Verify if all the 2.0 upgrade scripts have corresponding client-side scripts if necessary
      KULRICE-6878Update 2.2 branch from latest Rice trunk
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      It seems that the 1.0.3.2 fixes Chitra made fell through the cracks of our process and were not applied to the 2.0 branch. Please review and see if they were applied and if not, please apply them to the 2.0 trunk. Thanks!

      Also, Eric had the following comments on one of these items:
      [8/1/11 8:42:05 AM]basically in web.xml the following was changed:
      [8/1/11 8:43:04 AM] Eric Westfall: <servlet>
      <servlet-name>remoting</servlet-name>
      <servlet-class>org.kuali.rice.ksb.messaging.servlet.KSBDispatcherServlet</servlet-class>
      <load-on-startup>1</load-on-startup>
      </servlet>
      [8/1/11 8:43:05 AM] Eric Westfall: to:
      [8/1/11 8:43:32 AM] Eric Westfall: <servlet>
      <servlet-name>remoting</servlet-name>
      <servlet-class>org.kuali.rice.ksb.messaging.servlet.KSBDispatcherServlet</servlet-class>
      <init-param>
      <param-name>contextConfigLocation</param-name>
      <param-value>ksb/WEB-INF/remoting-servlet.xml</param-value>
      </init-param>
      <load-on-startup>1</load-on-startup>
      </servlet>
      [8/1/11 8:43:51 AM] Eric Westfall: if you don't pass in that contextConfigLocation, then application startup fails with an exception
      [8/1/11 8:44:13 AM] Eric Westfall: furthermore you have to manually copy that remoting-servlet.xml file over to your application and put it in the super-special place for it to get loaded
      [8/1/11 8:44:39 AM] Eric Westfall: we really should be defaulting that thing if we can, and pulling it from the classpath instead of the filesystem

        Activity

        Hide
        Shannon Hess added a comment -

        KULRICE-5071 was cloned to KULRICE-5288 for Rice 2.0 and changes were merged by James.
        KULRICE-5077 was cloned to KULRICE-5289 for Rice 2.0 and changes were merged by James.

        For KULRICE-5088, I can't get the following to work when testing due to having to get the Country Service in StateServiceImpl.java. Is my code correct, or am I going at this the wrong way?

        Code I added to StateServiceImpl.java:

        @Override
        public List<State> findAllStatesInCountryByAltCode(String alternateCode) {
        if (StringUtils.isBlank(alternateCode))

        { throw new RiceIllegalArgumentException(("alternateCode is null")); }

        Country country = getCountryService().getCountryByAlternateCode(alternateCode);

        if(country == null)

        { throw new RiceIllegalStateException("The alternateCode is not a valid Alternate Postal Country Code. alternateCode: " + alternateCode); }

        final List<State> toReturn = findAllStatesInCountry(country.getCode());
        return Collections.unmodifiableList(toReturn);
        }

        public CountryService getCountryService() {
        if (countryService == null)

        { countryService = SharedDataApiServiceLocator.getCountryService(); }

        return countryService;
        }

        Show
        Shannon Hess added a comment - KULRICE-5071 was cloned to KULRICE-5288 for Rice 2.0 and changes were merged by James. KULRICE-5077 was cloned to KULRICE-5289 for Rice 2.0 and changes were merged by James. For KULRICE-5088 , I can't get the following to work when testing due to having to get the Country Service in StateServiceImpl.java. Is my code correct, or am I going at this the wrong way? Code I added to StateServiceImpl.java: @Override public List<State> findAllStatesInCountryByAltCode(String alternateCode) { if (StringUtils.isBlank(alternateCode)) { throw new RiceIllegalArgumentException(("alternateCode is null")); } Country country = getCountryService().getCountryByAlternateCode(alternateCode); if(country == null) { throw new RiceIllegalStateException("The alternateCode is not a valid Alternate Postal Country Code. alternateCode: " + alternateCode); } final List<State> toReturn = findAllStatesInCountry(country.getCode()); return Collections.unmodifiableList(toReturn); } public CountryService getCountryService() { if (countryService == null) { countryService = SharedDataApiServiceLocator.getCountryService(); } return countryService; }
        Hide
        Shannon Hess added a comment -

        Adding Peter so he can take a look at my code and make suggestions.

        Show
        Shannon Hess added a comment - Adding Peter so he can take a look at my code and make suggestions.
        Hide
        Peter Giles (Inactive) added a comment - - edited

        Hi Shannon, it looks sane to me. I'm guessing that your issue is actually with the test configuration, i.e. there is no wiring present for the CountryService. If it doesn't undermine what you're trying to test then I would suggest adding a setter for the CountryService so that you can manually 'inject' a mock CountryService in an @Before method.

        Show
        Peter Giles (Inactive) added a comment - - edited Hi Shannon, it looks sane to me. I'm guessing that your issue is actually with the test configuration, i.e. there is no wiring present for the CountryService. If it doesn't undermine what you're trying to test then I would suggest adding a setter for the CountryService so that you can manually 'inject' a mock CountryService in an @Before method.
        Hide
        Chitra Chandran added a comment -

        Jessica,
        While working on the analysis for upgrading KC to rice 2.0, I find stuff missing in latest rice 2.0 trunk code that was introduced as part of Rice 1.0.3.1 release.

        Here are the details:
        New validation pattern introduced in 1.0.3.1 (for KULRICE-3997 jira) is missing in current rice 2.0 code.

        https://test.kuali.org/svn/rice/tags/rice-release-1-0-3-1-tag/kns/src/test/java/org/kuali/rice/kns/datadictionary/validation/charlevel/UTF8AnyCharacterValidationPatternTest.java

        Pls let me know if I need to log a different JIRA for this. Maybe this class was renamed or repackaged...
        I looked at the following project directory which contains all the other validation patterns and I don't see this.
        /rice_2-0/kns/src/main/java/org/kuali/rice/kns/datadictionary/validation/charlevel

        Also, this makes me wonder if there are other things that might have been missed after 1.0.3.1 was released. Is it possible to have that verified too while we are at this task?

        Thanks,
        Chitra

        Show
        Chitra Chandran added a comment - Jessica, While working on the analysis for upgrading KC to rice 2.0, I find stuff missing in latest rice 2.0 trunk code that was introduced as part of Rice 1.0.3.1 release. Here are the details: New validation pattern introduced in 1.0.3.1 (for KULRICE-3997 jira) is missing in current rice 2.0 code. https://test.kuali.org/svn/rice/tags/rice-release-1-0-3-1-tag/kns/src/test/java/org/kuali/rice/kns/datadictionary/validation/charlevel/UTF8AnyCharacterValidationPatternTest.java Pls let me know if I need to log a different JIRA for this. Maybe this class was renamed or repackaged... I looked at the following project directory which contains all the other validation patterns and I don't see this. /rice_2-0/kns/src/main/java/org/kuali/rice/kns/datadictionary/validation/charlevel Also, this makes me wonder if there are other things that might have been missed after 1.0.3.1 was released. Is it possible to have that verified too while we are at this task? Thanks, Chitra
        Hide
        Shannon Hess added a comment -

        – Applied changes for KULRICE-5088 to Rice 2.0
        – Verified UTF8AnyCharacterValidationPatternTest.java from KULRICE-3997 was missing from Rice 2.0, so I applied it and test cases to Rice 2.0

        JIRAS remaining to apply to 2.0:

        KULRICE-5010
        KULRICE-5089

        Show
        Shannon Hess added a comment - – Applied changes for KULRICE-5088 to Rice 2.0 – Verified UTF8AnyCharacterValidationPatternTest.java from KULRICE-3997 was missing from Rice 2.0, so I applied it and test cases to Rice 2.0 JIRAS remaining to apply to 2.0: KULRICE-5010 KULRICE-5089
        Hide
        Jeremy Hanson added a comment -

        UTF8AnyCharacterValidationPattern exists in 2.0. It is in the rice-kns module under this package: org.kuali.rice.kns.datadictionary.validation.charlevel

        Show
        Jeremy Hanson added a comment - UTF8AnyCharacterValidationPattern exists in 2.0. It is in the rice-kns module under this package: org.kuali.rice.kns.datadictionary.validation.charlevel
        Hide
        Shannon Hess added a comment -


        Yes, I just added org.kuali.rice.kns.datadictionary.validation.charlevel.UTF8AnyCharacterValidationPattern.java a couple of days ago.

        Show
        Shannon Hess added a comment - Yes, I just added org.kuali.rice.kns.datadictionary.validation.charlevel.UTF8AnyCharacterValidationPattern.java a couple of days ago.
        Hide
        Shannon Hess added a comment -

        I've made the code fix locally for KULRICE-5010 and KULRICE-5089, but it seems the build has been failing due to changes made to some of the same classes (From KULRICE-5357) so I'm going to wait to commit until the build is no longer failing.

        For KULRICE-5089, I was able to pull remoting-servlet.xml from the classpath instead of the filesystem, but I was not able to default it so if contextConfigLocation is not passed in then the application startup fails with an exception

        Show
        Shannon Hess added a comment - I've made the code fix locally for KULRICE-5010 and KULRICE-5089 , but it seems the build has been failing due to changes made to some of the same classes (From KULRICE-5357 ) so I'm going to wait to commit until the build is no longer failing. For KULRICE-5089 , I was able to pull remoting-servlet.xml from the classpath instead of the filesystem, but I was not able to default it so if contextConfigLocation is not passed in then the application startup fails with an exception
        Hide
        Shannon Hess added a comment -

        All code for this JIRA has been committed. For KULRICE-5089 (KSBDispatcherServlet changes in web.xml), the client application has to do one or the other.

        1. Copy the init-param below into their remoting servlet OR
        2. Copy remoting-servlet.xml into /WEB-INF/remoting-servlet.xml since that is the default location.

        For the test clients, I went with option #1. If neither option is done, the the following error will be thrown at start-up:

        org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from ServletContext resource [/WEB-INF/remoting-servlet.xml]; nested exception is java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/remoting-servlet.xml] Caused by: java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/remoting-servlet.xml]

        init-param –

        <servlet-name>remoting</servlet-name>
        ...
        <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>classpath:org/kuali/rice/ksb/config/remoting-servlet.xml</param-value>
        </init-param>
        ...
        </servlet>

        Show
        Shannon Hess added a comment - All code for this JIRA has been committed. For KULRICE-5089 (KSBDispatcherServlet changes in web.xml), the client application has to do one or the other. 1. Copy the init-param below into their remoting servlet OR 2. Copy remoting-servlet.xml into /WEB-INF/remoting-servlet.xml since that is the default location. For the test clients, I went with option #1. If neither option is done, the the following error will be thrown at start-up: org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from ServletContext resource [/WEB-INF/remoting-servlet.xml] ; nested exception is java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/remoting-servlet.xml] Caused by: java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/remoting-servlet.xml] init-param – <servlet-name>remoting</servlet-name> ... <init-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:org/kuali/rice/ksb/config/remoting-servlet.xml</param-value> </init-param> ... </servlet>

          People

          • Assignee:
            Shannon Hess
            Reporter:
            Matt Sargent
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel