Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-11951

DatePatternConstraint doesn't handle missing config param properly

    Details

    • Type: Bug Fix
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.4
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Sprint:
      2.4.0-rc1 Sprint 4
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      DatePatternConstraint.java requires a config param to be set. This is not clear and when not set, exceptions are swallowed. Proposed solution:

      Create spring beans for STRING_TO_DATE_FORMATS and others in common-config-defaults.xml. If a config param is encountered use that in lieu of the spring beans to protect existing

      This came out of a discussion with Brian (he's probably the most qualified to handle this).

        Attachments

          Activity

          Hide
          cniesen Claus Niesen added a comment -

          [this] one means a way to set that STRING_TO_DATE_FORMATS setting in the xml
          one means a way to set that STRING_TO_DATE_FORMATS setting in the xml

          Show
          cniesen Claus Niesen added a comment - [this] one means a way to set that STRING_TO_DATE_FORMATS setting in the xml one means a way to set that STRING_TO_DATE_FORMATS setting in the xml
          Hide
          kbtaylor Kristina Taylor (Inactive) added a comment - - edited

          I'm somewhat confused by your situation. Do you have a config file that overrides STRING_TO_DATE_FORMATS with an empty string? If you don't override them then you should be picking up the defaults.

          Either way, putting spring beans in common-config-defaults.xml is impossible. If you wanted an internal Rice default for these strings in cases where these were accidentally emptied out, the best way to handle this would probably be to use the DateTimeService which contains defaults and already covers this case for other validators.

          Show
          kbtaylor Kristina Taylor (Inactive) added a comment - - edited I'm somewhat confused by your situation. Do you have a config file that overrides STRING_TO_DATE_FORMATS with an empty string? If you don't override them then you should be picking up the defaults. Either way, putting spring beans in common-config-defaults.xml is impossible. If you wanted an internal Rice default for these strings in cases where these were accidentally emptied out, the best way to handle this would probably be to use the DateTimeService which contains defaults and already covers this case for other validators.
          Hide
          lsymms Larry Symms added a comment -

          If we don't supply STRING_TO_DATE_FORMATS as a rice param or property our application fails to start because our validation framework depends on DatePatternConstraint through the DD validation framework used by KRAD bean configurations. The issue I have is that rice provides this constraint but it's not fully configured by default. Why for this one constraint do we have to supply a pile of string formats?

          Show
          lsymms Larry Symms added a comment - If we don't supply STRING_TO_DATE_FORMATS as a rice param or property our application fails to start because our validation framework depends on DatePatternConstraint through the DD validation framework used by KRAD bean configurations. The issue I have is that rice provides this constraint but it's not fully configured by default. Why for this one constraint do we have to supply a pile of string formats?
          Hide
          kbtaylor Kristina Taylor (Inactive) added a comment -

          That's the strange thing, you shouldn't have to unless you aren't loading common-config-defaults.xml by default when you start up. I think your concerns are valid though and that we should have a programmed default like this just in case someone empties out this parameter, but I'm actually more concerned about your startup and that you are either not loading this file or that it is being overridden somewhere else. Projects that I have worked on (KC, KPME) never required supplying this parameter in their project configs or developer configs and Rice developers do not have to supply it in their developer configs either even when we use the DatePatternConstraint in the application. You might want additionally check your configurations to see if there's a deeper problem.

          Show
          kbtaylor Kristina Taylor (Inactive) added a comment - That's the strange thing, you shouldn't have to unless you aren't loading common-config-defaults.xml by default when you start up. I think your concerns are valid though and that we should have a programmed default like this just in case someone empties out this parameter, but I'm actually more concerned about your startup and that you are either not loading this file or that it is being overridden somewhere else. Projects that I have worked on (KC, KPME) never required supplying this parameter in their project configs or developer configs and Rice developers do not have to supply it in their developer configs either even when we use the DatePatternConstraint in the application. You might want additionally check your configurations to see if there's a deeper problem.
          Hide
          lsymms Larry Symms added a comment -

          here's our module config:

          <bean id="kualiModuleService" class="org.kuali.rice.krad.service.impl.KualiModuleServiceImpl" />

          <bean id="studentRiceModule" class="org.kuali.rice.krad.service.impl.ModuleServiceBase">
          <property name="moduleConfiguration" ref="studentRiceModuleConfiguration" />
          <property name="kualiModuleService" ref="kualiModuleService" />
          </bean>

          <bean id="studentRiceModuleConfiguration" class="org.kuali.rice.krad.bo.ModuleConfiguration">
          <property name="namespaceCode" value="KS-SYS" />
          <property name="initializeDataDictionary" value="true" />
          <property name="dataDictionaryPackages">

          <bean class="org.kuali.student.common.spring.CollectionAggregatingFactoryBean">
          <property name="collectionBeanReferences" >
          <list>
          <value>ks-core-krad-data-dictionary-config</value>
          <value>ks-enroll-krad-data-dictionary-config</value>
          <value>ks-ap-krad-data-dictionary-config</value>
          <value>ks-cm-krad-data-dictionary-config</value>
          </list>
          </property>
          </bean>

          </property>

          <property name="packagePrefixes">
          <list>
          <value>org.kuali.rice.student.</value>
          <value>org.kuali.student.enrollment.</value>
          </list>
          </property>
          </bean>

          Show
          lsymms Larry Symms added a comment - here's our module config: <bean id="kualiModuleService" class="org.kuali.rice.krad.service.impl.KualiModuleServiceImpl" /> <bean id="studentRiceModule" class="org.kuali.rice.krad.service.impl.ModuleServiceBase"> <property name="moduleConfiguration" ref="studentRiceModuleConfiguration" /> <property name="kualiModuleService" ref="kualiModuleService" /> </bean> <bean id="studentRiceModuleConfiguration" class="org.kuali.rice.krad.bo.ModuleConfiguration"> <property name="namespaceCode" value="KS-SYS" /> <property name="initializeDataDictionary" value="true" /> <property name="dataDictionaryPackages"> <bean class="org.kuali.student.common.spring.CollectionAggregatingFactoryBean"> <property name="collectionBeanReferences" > <list> <value>ks-core-krad-data-dictionary-config</value> <value>ks-enroll-krad-data-dictionary-config</value> <value>ks-ap-krad-data-dictionary-config</value> <value>ks-cm-krad-data-dictionary-config</value> </list> </property> </bean> </property> <property name="packagePrefixes"> <list> <value>org.kuali.rice.student.</value> <value>org.kuali.student.enrollment.</value> </list> </property> </bean>
          Hide
          kbtaylor Kristina Taylor (Inactive) added a comment - - edited

          It actually goes much deeper than that, when you reach back to your bootstrap spring beans. As an example, KPME loads the file kpme-bootstrap-springbeans.xml on startup and they have an entry

          <bean id="bootstrapConfig" class="org.kuali.rice.core.impl.config.property.ConfigFactoryBean">
            <property name="configLocations">
              <list>
                <value>classpath:META-INF/kpme-config.xml</value>
              </list>
            </property>
          </bean>
          

          and in kpme-config.xml they have the entry

          <!-- Rice project defaults: Contains properties that may not be set by KPME defaults.  These properties should never override. -->
          <param name="config.location">classpath:META-INF/common-config-defaults.xml</param>
          

          which performs the import. I'm noticing via Fisheye that KS does this in many places, so it is very odd that you are having this startup problem. I'm not so concerned about this issue as I am when we add additional parameters to this file. I recently added one myself to 2.4 for handling Time fields.

          Show
          kbtaylor Kristina Taylor (Inactive) added a comment - - edited It actually goes much deeper than that, when you reach back to your bootstrap spring beans. As an example, KPME loads the file kpme-bootstrap-springbeans.xml on startup and they have an entry <bean id= "bootstrapConfig" class= "org.kuali.rice.core.impl.config.property.ConfigFactoryBean" > <property name= "configLocations" > <list> <value>classpath:META-INF/kpme-config.xml</value> </list> </property> </bean> and in kpme-config.xml they have the entry <!-- Rice project defaults: Contains properties that may not be set by KPME defaults. These properties should never override. --> <param name= "config.location" >classpath:META-INF/common-config-defaults.xml</param> which performs the import. I'm noticing via Fisheye that KS does this in many places, so it is very odd that you are having this startup problem. I'm not so concerned about this issue as I am when we add additional parameters to this file. I recently added one myself to 2.4 for handling Time fields.

            People

            • Assignee:
              kbtaylor Kristina Taylor (Inactive)
              Reporter:
              lsymms Larry Symms
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1 day
                1d
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 hours Time Not Required
                2h