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

Business object validation is validating reference objects when it should not

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.1.1
    • Fix Version/s: 2.1.2
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-13198NPE when I subclass a business object
      KULRICE-7369Implement KRMS Reference Object Bindings feature
      KULRICE-9287KualiLookupableTest fails in CI with Lookup not defined for business object class org.kuali.rice.krad.test.document.bo.Account
      KULRICE-1312Create Business Objects for KOM
      KULRICE-3716Create a "Business Object Observer" framework
      KULRICE-6045Add coverage of Externalizable Business Objects to Rice docs
      KULRICE-1551Build KOM business objects
      KULRICE-4736Support for dynamic business objects
      KULRICE-2171Create Implementation classes for KIM Reference objects
      KULRICE-1482Add new Principal business object
    • Rice Module:
      KNS, KRAD
    • KRAD Feature Area:
      Data Dictionary
    • Application Requirement:
      KFS
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      It looks like something changed in the way that validation works on objects and their related child objects in Rice 2.0. Business object validation is apparently validating child objects which are not updatable. I don't know precisely what it was doing before. But, now we have documents failing because the BO-level validation is firing and then blocking the document if there is anything wrong with any of the objects which have been referenced. And, it seems to be running fairly deep, as I've encountered materialization of child objects I would not have expected from a KFS accounting line validation, since the object in question was 3 levels down and not in any way related to any business rules.

      This will be a major problem for implementors, as each chooses to use some fields on objects and not others. Or, they may have loaded data into the tables which will not validate (missing fields which are marked as required - but do not affect day-to-day operations.)

        Issue Links

          Activity

          Hide
          Jonathan Keller added a comment -

          I found the problem on this one. There is a behavior change in Rice with the validator.

          The BO validation used to run off of the properties on the Java class. It now runs off of the attributes referenced in the data dictionary. This, at the very least, is a behavior change clients may not be expecting, since it is common to add child attributes of reference objects into the DD attributes so they can be used in the maintenance document framework.

          Is this a place where the KNS DataDictionaryValidationService could override the KRAD version to restore the original behavior?

          Show
          Jonathan Keller added a comment - I found the problem on this one. There is a behavior change in Rice with the validator. The BO validation used to run off of the properties on the Java class. It now runs off of the attributes referenced in the data dictionary. This, at the very least, is a behavior change clients may not be expecting, since it is common to add child attributes of reference objects into the DD attributes so they can be used in the maintenance document framework. Is this a place where the KNS DataDictionaryValidationService could override the KRAD version to restore the original behavior?
          Hide
          Eric Westfall added a comment -

          Assigning to Martin.

          Martin, it looks like this is a situation where changes in KRAD are impacting legacy functionality of the KNS. Can you explore Jonathan's suggestion of setting this up so that it works the way it used to for KNS? If that's not possible, maybe talk with the KRAD team about why the particular change was made in KRAD? Thanks.

          Show
          Eric Westfall added a comment - Assigning to Martin. Martin, it looks like this is a situation where changes in KRAD are impacting legacy functionality of the KNS. Can you explore Jonathan's suggestion of setting this up so that it works the way it used to for KNS? If that's not possible, maybe talk with the KRAD team about why the particular change was made in KRAD? Thanks.
          Hide
          Martin Taylor (Inactive) added a comment -

          @Jonathan: Can you provide a test case for this on kfs/kr?

          Notes: reviewing BaseBOClassAndBaseDocumentObjectTest and its completeValidation calls

          Show
          Martin Taylor (Inactive) added a comment - @Jonathan: Can you provide a test case for this on kfs/kr? Notes: reviewing BaseBOClassAndBaseDocumentObjectTest and its completeValidation calls
          Hide
          Jonathan Keller added a comment -

          Sure: Copying in some notes from an email discussion I had with the KFS team:

          Apparently, when we run the validations on accounting lines within transactional documents, it is validating the child objects. That is, it's running the DD business-object level validation on all the Account/Sub Account/Object data. This was not happening in Rice 1.0.3.3 - bad child object data did not stop the documents using them from routing. (Unless it were somehow used in a validation.)

          It looks like BO validation has extended into objects which are not updatable from the source object. I'm going to open a rice ticket for this one as well.

          (To reproduce the error below (now attached to JIRA), set the HEFC code to null for a given account:
          UPDATE CA_ACCOUNT_T
          SET FIN_HGH_ED_FUNC_CD = NULL
          WHERE ACCOUNT_NBR = '1031400'
          )

          Yep - found the change in KRAD. In Rice 1.0.3.3, the system looped over the properties on the BO class, then looked for validation information in the DD:

          validatePrimitivesFromDescriptors(businessObject.getClass().getName(), businessObject, PropertyUtils.getPropertyDescriptors(businessObject.getClass()), "", validateRequired);

          In Rice 2.0, it now uses the DD first, pulling the attribute definitions:

          DataDictionaryEntry entry = getDataDictionaryService().getDataDictionary().getDictionaryObjectEntry(entryName);
          AttributeValueReader attributeValueReader = new DictionaryObjectAttributeValueReader(object, entryName, entry);

          This is causing the validation of attributes which was not being done in KFS 4.1.1.

          I don't know whether this is good or bad, but it can potentially result in strange error for implementors and requires a different mindset when defining the attributes on a business object.

          Show
          Jonathan Keller added a comment - Sure: Copying in some notes from an email discussion I had with the KFS team: Apparently, when we run the validations on accounting lines within transactional documents, it is validating the child objects . That is, it's running the DD business-object level validation on all the Account/Sub Account/Object data. This was not happening in Rice 1.0.3.3 - bad child object data did not stop the documents using them from routing. (Unless it were somehow used in a validation.) It looks like BO validation has extended into objects which are not updatable from the source object. I'm going to open a rice ticket for this one as well. (To reproduce the error below (now attached to JIRA), set the HEFC code to null for a given account: UPDATE CA_ACCOUNT_T SET FIN_HGH_ED_FUNC_CD = NULL WHERE ACCOUNT_NBR = '1031400' ) Yep - found the change in KRAD. In Rice 1.0.3.3, the system looped over the properties on the BO class, then looked for validation information in the DD: validatePrimitivesFromDescriptors(businessObject.getClass().getName(), businessObject, PropertyUtils.getPropertyDescriptors(businessObject.getClass()), "", validateRequired); In Rice 2.0, it now uses the DD first, pulling the attribute definitions: DataDictionaryEntry entry = getDataDictionaryService().getDataDictionary().getDictionaryObjectEntry(entryName); AttributeValueReader attributeValueReader = new DictionaryObjectAttributeValueReader(object, entryName, entry); This is causing the validation of attributes which was not being done in KFS 4.1.1. I don't know whether this is good or bad, but it can potentially result in strange error for implementors and requires a different mindset when defining the attributes on a business object.
          Hide
          Peter Giles (Inactive) added a comment -

          I notice that the DictionaryValidationServiceImpl being used by the rules for the Budget Adjustment doc is the one for KRAD rather than KNS. Will look into that more.

          Show
          Peter Giles (Inactive) added a comment - I notice that the DictionaryValidationServiceImpl being used by the rules for the Budget Adjustment doc is the one for KRAD rather than KNS. Will look into that more.
          Hide
          Peter Giles (Inactive) added a comment -

          After adding an overridden AccountingRuleEngineRuleBase.getDictionaryValidationService() that returns the KNS impl, I am able to submit the document successfully with the values shown in the attached screenshot (with the addition of setting "Base Amt" in the From/Decrease and To/Increase lines to 10 each – just winged that since it isn't shown above).

          AccountingRuleEngineRuleBase is extending DocumentRuleBase directly, which there is only one of, instead of extending MaintenanceDocumentRuleBase or TransactionalDocumentRuleBase, which have both KNS and KRAD versions. Do we need to push this split further up the hierarchy and have two versions of DocumentRuleBase as well?

          Show
          Peter Giles (Inactive) added a comment - After adding an overridden AccountingRuleEngineRuleBase.getDictionaryValidationService() that returns the KNS impl, I am able to submit the document successfully with the values shown in the attached screenshot (with the addition of setting "Base Amt" in the From/Decrease and To/Increase lines to 10 each – just winged that since it isn't shown above). AccountingRuleEngineRuleBase is extending DocumentRuleBase directly, which there is only one of, instead of extending MaintenanceDocumentRuleBase or TransactionalDocumentRuleBase, which have both KNS and KRAD versions. Do we need to push this split further up the hierarchy and have two versions of DocumentRuleBase as well?
          Hide
          Muddu Salem added a comment -

          Peter,

          Do you want to me to implement the change that your mentioned above to get KNS impl and try purap documents?

          Show
          Muddu Salem added a comment - Peter, Do you want to me to implement the change that your mentioned above to get KNS impl and try purap documents?
          Hide
          Peter Giles (Inactive) added a comment -

          I've added a kns version of DocumentRuleBase, I'd like to have KFS extend that one anywhere you are currently extending the krad one.

          Show
          Peter Giles (Inactive) added a comment - I've added a kns version of DocumentRuleBase, I'd like to have KFS extend that one anywhere you are currently extending the krad one.
          Hide
          Muddu Salem added a comment -

          There are 7 classes that are referencing krad DocumentRuleBase now that I can easily change to kns version. I need to wait for the latest rice changes though.

          Show
          Muddu Salem added a comment - There are 7 classes that are referencing krad DocumentRuleBase now that I can easily change to kns version. I need to wait for the latest rice changes though.
          Hide
          Jonathan Keller added a comment -

          Question - are the KNS specializations of DocumentRuleBase which exist in Rice also extending this new class? Or, are they inheriting from the KRAD version?

          I just want to make sure there is not a code path which uses the "new" validation code.

          Show
          Jonathan Keller added a comment - Question - are the KNS specializations of DocumentRuleBase which exist in Rice also extending this new class? Or, are they inheriting from the KRAD version? I just want to make sure there is not a code path which uses the "new" validation code.
          Hide
          Peter Giles (Inactive) added a comment -

          I restructured the class hierarchy so that the kns' MaintenanceDocumentRuleBase and TransactionalDocumentRuleBase extend the kns' DocumentRuleBase. I think that is what you were getting at, let me know if I'm wrong. I believe we are covered.

          Show
          Peter Giles (Inactive) added a comment - I restructured the class hierarchy so that the kns' MaintenanceDocumentRuleBase and TransactionalDocumentRuleBase extend the kns' DocumentRuleBase. I think that is what you were getting at, let me know if I'm wrong. I believe we are covered.
          Hide
          Jessica Coltrin (Inactive) added a comment -

          This one should be applied to the 2.1-kfs branch that we'll later tag as 2.1.2-rc1 for the KFS 5.0 release.

          Show
          Jessica Coltrin (Inactive) added a comment - This one should be applied to the 2.1-kfs branch that we'll later tag as 2.1.2-rc1 for the KFS 5.0 release.
          Hide
          Peter Giles (Inactive) added a comment -

          The fix was applied to the rice-2.1-kfs sandbox branch. Resolving.

          Show
          Peter Giles (Inactive) added a comment - The fix was applied to the rice-2.1-kfs sandbox branch. Resolving.
          Hide
          Peter Giles (Inactive) added a comment -

          I just noticed that a number of KIM rule classes are extending the KRAD DocumentRuleBase. I think that should change, but I'm somewhat worried about doing that at the last second before we release. I'm thinking that change should go into 2.1.3.

          Jonathan, what is your opinion on that one?

          Show
          Peter Giles (Inactive) added a comment - I just noticed that a number of KIM rule classes are extending the KRAD DocumentRuleBase. I think that should change, but I'm somewhat worried about doing that at the last second before we release. I'm thinking that change should go into 2.1.3. Jonathan, what is your opinion on that one?
          Hide
          Jonathan Keller added a comment -

          Those documents are so strange. I'd just leave it for now since they seem to be working. Agreed : look into it in 2.1.3. But, the way they are coded, it may not make a difference to them. It only matters if their BO DD files have attributes with properties with "." in the property name.

          Show
          Jonathan Keller added a comment - Those documents are so strange. I'd just leave it for now since they seem to be working. Agreed : look into it in 2.1.3. But, the way they are coded, it may not make a difference to them. It only matters if their BO DD files have attributes with properties with "." in the property name.
          Hide
          Muddu Salem added a comment -

          The fix is working correctly in embedded mode but PO is giving a validation error in standalone mode. PO has a transient property statusChanged and we have bean defintion for it in purchase order DD xml. While trying to save the PO, we get the error "The Waiting on Additional Info (Status Change) may only consist of visible characters.".

          I tested this in both 5.0 and 5.0.1 under embedded mode and did not see the same error and the PO can be saved or submitted without any problem.

          Show
          Muddu Salem added a comment - The fix is working correctly in embedded mode but PO is giving a validation error in standalone mode. PO has a transient property statusChanged and we have bean defintion for it in purchase order DD xml. While trying to save the PO, we get the error "The Waiting on Additional Info (Status Change) may only consist of visible characters.". I tested this in both 5.0 and 5.0.1 under embedded mode and did not see the same error and the PO can be saved or submitted without any problem.
          Hide
          Muddu Salem added a comment -

          On our maintenance documents, we are getting NPEs and I will reopen this issue.

          *****************Stack Trace-Only shown when not in production****************

          java.lang.NullPointerException
          at org.kuali.rice.krad.rules.DocumentRuleBase.isDocumentOverviewValid(DocumentRuleBase.java:99)
          at org.kuali.rice.kns.maintenance.rules.MaintenanceDocumentRuleBase.isDocumentValidForSave(MaintenanceDocumentRuleBase.java:955)
          at org.kuali.rice.kns.maintenance.rules.MaintenanceDocumentRuleBase.processSaveDocument(MaintenanceDocumentRuleBase.java:163)
          at org.kuali.rice.krad.rules.rule.event.SaveDocumentEvent.invokeRuleMethod(SaveDocumentEvent.java:71)
          at org.kuali.rice.krad.service.impl.KualiRuleServiceImpl.applyRules(KualiRuleServiceImpl.java:85)
          at org.kuali.rice.krad.service.impl.KualiRuleServiceImpl.applyRules(KualiRuleServiceImpl.java:81)
          at org.kuali.rice.krad.maintenance.MaintenanceDocumentBase.validateBusinessRules(MaintenanceDocumentBase.java:825)
          at org.kuali.rice.krad.service.impl.DocumentServiceImpl.validateAndPersistDocument(DocumentServiceImpl.java:828)
          at org.kuali.rice.krad.service.impl.DocumentServiceImpl.routeDocument(DocumentServiceImpl.java:191)
          at org.kuali.rice.kns.web.struts.action.KualiDocumentActionBase.route(KualiDocumentActionBase.java:801)
          at org.kuali.rice.kns.web.struts.action.KualiMaintenanceDocumentAction.route(KualiMaintenanceDocumentAction.java:599)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
          at java.lang.reflect.Method.invoke(Unknown Source)
          at org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:269)
          at org.kuali.rice.kns.web.struts.action.KualiAction.dispatchMethod(KualiAction.java:168)
          at org.kuali.rice.kns.web.struts.action.KualiAction.execute(KualiAction.java:129)
          at org.kuali.rice.kns.web.struts.action.KualiDocumentActionBase.execute(KualiDocumentActionBase.java:174)
          at org.kuali.rice.kns.web.struts.action.KualiMaintenanceDocumentAction.execute(KualiMaintenanceDocumentAction.java:101)
          at org.kuali.rice.kns.web.struts.action.KualiRequestProcessor$1.doInTransaction(KualiRequestProcessor.java:486)
          at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130)
          at org.kuali.rice.kns.web.struts.action.KualiRequestProcessor.processActionPerform(KualiRequestProcessor.java:482)
          at org.kuali.rice.kns.web.struts.action.KualiRequestProcessor.processFormActionAndForward(KualiRequestProcessor.java:215)
          at org.kuali.rice.kns.web.struts.action.KualiRequestProcessor.strutsProcess(KualiRequestProcessor.java:202)
          at org.kuali.rice.kns.web.struts.action.KualiRequestProcessor.process(KualiRequestProcessor.java:89)
          at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913)
          at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
          at org.kuali.rice.kew.web.UserPreferencesFilter.doFilter(UserPreferencesFilter.java:78)
          at org.kuali.rice.kew.web.UserPreferencesFilter.doFilter(UserPreferencesFilter.java:62)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
          at org.kuali.rice.kew.web.UserLoginFilter.doFilter(UserLoginFilter.java:89)
          at org.kuali.rice.kew.web.UserLoginFilter.doFilter(UserLoginFilter.java:77)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
          at org.kuali.rice.kew.web.BootstrapFilter.doFilter(BootstrapFilter.java:162)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
          at org.kuali.kfs.sys.web.filter.DevelopmentLoginFilter.doFilter(DevelopmentLoginFilter.java:66)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
          at org.displaytag.filter.ResponseOverrideFilter.doFilter(ResponseOverrideFilter.java:125)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
          at org.kuali.rice.krad.web.filter.HideWebInfFilter.doFilter(HideWebInfFilter.java:69)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
          at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:202)
          at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:175)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
          at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
          at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
          at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:470)
          at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
          at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
          at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
          at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
          at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
          at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
          at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
          at java.lang.Thread.run(Unknown Source)

          Show
          Muddu Salem added a comment - On our maintenance documents, we are getting NPEs and I will reopen this issue. ***************** Stack Trace-Only shown when not in production **************** java.lang.NullPointerException at org.kuali.rice.krad.rules.DocumentRuleBase.isDocumentOverviewValid(DocumentRuleBase.java:99) at org.kuali.rice.kns.maintenance.rules.MaintenanceDocumentRuleBase.isDocumentValidForSave(MaintenanceDocumentRuleBase.java:955) at org.kuali.rice.kns.maintenance.rules.MaintenanceDocumentRuleBase.processSaveDocument(MaintenanceDocumentRuleBase.java:163) at org.kuali.rice.krad.rules.rule.event.SaveDocumentEvent.invokeRuleMethod(SaveDocumentEvent.java:71) at org.kuali.rice.krad.service.impl.KualiRuleServiceImpl.applyRules(KualiRuleServiceImpl.java:85) at org.kuali.rice.krad.service.impl.KualiRuleServiceImpl.applyRules(KualiRuleServiceImpl.java:81) at org.kuali.rice.krad.maintenance.MaintenanceDocumentBase.validateBusinessRules(MaintenanceDocumentBase.java:825) at org.kuali.rice.krad.service.impl.DocumentServiceImpl.validateAndPersistDocument(DocumentServiceImpl.java:828) at org.kuali.rice.krad.service.impl.DocumentServiceImpl.routeDocument(DocumentServiceImpl.java:191) at org.kuali.rice.kns.web.struts.action.KualiDocumentActionBase.route(KualiDocumentActionBase.java:801) at org.kuali.rice.kns.web.struts.action.KualiMaintenanceDocumentAction.route(KualiMaintenanceDocumentAction.java:599) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:269) at org.kuali.rice.kns.web.struts.action.KualiAction.dispatchMethod(KualiAction.java:168) at org.kuali.rice.kns.web.struts.action.KualiAction.execute(KualiAction.java:129) at org.kuali.rice.kns.web.struts.action.KualiDocumentActionBase.execute(KualiDocumentActionBase.java:174) at org.kuali.rice.kns.web.struts.action.KualiMaintenanceDocumentAction.execute(KualiMaintenanceDocumentAction.java:101) at org.kuali.rice.kns.web.struts.action.KualiRequestProcessor$1.doInTransaction(KualiRequestProcessor.java:486) at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130) at org.kuali.rice.kns.web.struts.action.KualiRequestProcessor.processActionPerform(KualiRequestProcessor.java:482) at org.kuali.rice.kns.web.struts.action.KualiRequestProcessor.processFormActionAndForward(KualiRequestProcessor.java:215) at org.kuali.rice.kns.web.struts.action.KualiRequestProcessor.strutsProcess(KualiRequestProcessor.java:202) at org.kuali.rice.kns.web.struts.action.KualiRequestProcessor.process(KualiRequestProcessor.java:89) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.kuali.rice.kew.web.UserPreferencesFilter.doFilter(UserPreferencesFilter.java:78) at org.kuali.rice.kew.web.UserPreferencesFilter.doFilter(UserPreferencesFilter.java:62) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.kuali.rice.kew.web.UserLoginFilter.doFilter(UserLoginFilter.java:89) at org.kuali.rice.kew.web.UserLoginFilter.doFilter(UserLoginFilter.java:77) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.kuali.rice.kew.web.BootstrapFilter.doFilter(BootstrapFilter.java:162) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.kuali.kfs.sys.web.filter.DevelopmentLoginFilter.doFilter(DevelopmentLoginFilter.java:66) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.displaytag.filter.ResponseOverrideFilter.doFilter(ResponseOverrideFilter.java:125) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.kuali.rice.krad.web.filter.HideWebInfFilter.doFilter(HideWebInfFilter.java:69) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:202) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:175) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:470) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) at java.lang.Thread.run(Unknown Source)
          Hide
          Muddu Salem added a comment -

          Getting NPEs on maintenance document submission.

          Show
          Muddu Salem added a comment - Getting NPEs on maintenance document submission.
          Hide
          Peter Giles (Inactive) added a comment -

          Hi Muddu, I've identified the issue and will be committing a fix in a few minutes.

          Show
          Peter Giles (Inactive) added a comment - Hi Muddu, I've identified the issue and will be committing a fix in a few minutes.
          Hide
          Peter Giles (Inactive) added a comment -

          I'm unable to reproduce this issue running standalone against the latest of either the rice-2.1 branch or the rice-2.1-kfs branch. I've verified that the run modes of all modules on my local instance match those of the int.kfs.kuali.org server:

          core.mode=LOCAL
          coreservice.mode=REMOTE
          edl.mode=LOCAL
          ken.mode=REMOTE
          kew.mode=EMBEDDED
          kfs.mode=LOCAL
          kim.mode=EMBEDDED
          kr.mode=LOCAL
          krad.mode=LOCAL
          krms.mode=REMOTE
          ksb.mode=REMOTE
          location.mode=REMOTE

          As mentioned in chat, when I'm looking at the validation of PurchaseOrderDocument.statusChange on a "save" action in the debugger, the field has a value of "In Process" and validation passes.

          Show
          Peter Giles (Inactive) added a comment - I'm unable to reproduce this issue running standalone against the latest of either the rice-2.1 branch or the rice-2.1-kfs branch. I've verified that the run modes of all modules on my local instance match those of the int.kfs.kuali.org server: core.mode=LOCAL coreservice.mode=REMOTE edl.mode=LOCAL ken.mode=REMOTE kew.mode=EMBEDDED kfs.mode=LOCAL kim.mode=EMBEDDED kr.mode=LOCAL krad.mode=LOCAL krms.mode=REMOTE ksb.mode=REMOTE location.mode=REMOTE As mentioned in chat, when I'm looking at the validation of PurchaseOrderDocument.statusChange on a "save" action in the debugger, the field has a value of "In Process" and validation passes.
          Hide
          Muddu Salem added a comment -

          This is the log I am seeing when I am trying to save a PO. This is in embedded mode.

          2012-09-12 09:00:40,098 [http-8080-4] u:parke/d: INFO org.kuali.rice.krad.document.DocumentBase :: invoking rules engine on document 6873
          2012-09-12 09:00:40,098 [http-8080-4] u:parke/d: INFO org.kuali.kfs.module.purap.document.PurchasingAccountsPayableDocumentBase :: Checking persisted source accounting lines for read-only fields
          2012-09-12 09:00:40,302 [http-8080-4] u:parke/d: INFO org.kuali.kfs.module.purap.document.PurchasingAccountsPayableDocumentBase :: Checking source accounting lines for read-only fields
          2012-09-12 09:00:41,994 [http-8080-4] u:parke/d: INFO org.kuali.rice.krad.document.DocumentBase :: [document.item[1].sourceAccountingLines[0].document.statusChange] error.format.org.kuali.rice.kns.datadictionary.validation.charlevel.AnyCharacterValidationPattern(Waiting on Additional Info (Status Change))
          2012-09-12 09:00:46,351 [http-8080-4] u:parke/d: WARN org.apache.struts.util.PropertyMessageResources :: Resource org/kuali/rice/krad/ApplicationResources_en_US.properties Not Found.

          Show
          Muddu Salem added a comment - This is the log I am seeing when I am trying to save a PO. This is in embedded mode. 2012-09-12 09:00:40,098 [http-8080-4] u:parke/d: INFO org.kuali.rice.krad.document.DocumentBase :: invoking rules engine on document 6873 2012-09-12 09:00:40,098 [http-8080-4] u:parke/d: INFO org.kuali.kfs.module.purap.document.PurchasingAccountsPayableDocumentBase :: Checking persisted source accounting lines for read-only fields 2012-09-12 09:00:40,302 [http-8080-4] u:parke/d: INFO org.kuali.kfs.module.purap.document.PurchasingAccountsPayableDocumentBase :: Checking source accounting lines for read-only fields 2012-09-12 09:00:41,994 [http-8080-4] u:parke/d: INFO org.kuali.rice.krad.document.DocumentBase :: [document.item [1] .sourceAccountingLines [0] .document.statusChange] error.format.org.kuali.rice.kns.datadictionary.validation.charlevel.AnyCharacterValidationPattern(Waiting on Additional Info (Status Change)) 2012-09-12 09:00:46,351 [http-8080-4] u:parke/d: WARN org.apache.struts.util.PropertyMessageResources :: Resource org/kuali/rice/krad/ApplicationResources_en_US.properties Not Found.
          Hide
          Peter Giles (Inactive) added a comment - - edited

          I figured out this morning that the different behavior I was seeing was due to KFS moving on to a 5.0.1 branch, while I was still on 5.0.

          I believe that what remains is to analyze why more validation is occurring now that the KNS' DocumentRuleBase (and hence DictionaryValidationServiceImpl) is occurring. The answer is that KRAD's validation code doesn't pay any attention to the ValidationPatterns KFS has in its DD, instead it requires the use of Constraint classes (e.g. ValidationCharactersConstraint). So the DD definitions would have to be changed to add similar validation that would function with the KRAD DictionaryValidationServiceImpl. Examples of the difference can be found here: https://wiki.kuali.org/display/KULRICE/Data+Dictionary+Constraints

          Show
          Peter Giles (Inactive) added a comment - - edited I figured out this morning that the different behavior I was seeing was due to KFS moving on to a 5.0.1 branch, while I was still on 5.0. I believe that what remains is to analyze why more validation is occurring now that the KNS' DocumentRuleBase (and hence DictionaryValidationServiceImpl) is occurring. The answer is that KRAD's validation code doesn't pay any attention to the ValidationPatterns KFS has in its DD, instead it requires the use of Constraint classes (e.g. ValidationCharactersConstraint). So the DD definitions would have to be changed to add similar validation that would function with the KRAD DictionaryValidationServiceImpl. Examples of the difference can be found here: https://wiki.kuali.org/display/KULRICE/Data+Dictionary+Constraints
          Hide
          Ailish Byrne added a comment -

          not possible till we move to krad. this will need to be fixed another way. we certainly can't do something like this with a version of kfs that was supposed to be release 6 months ago.

          Show
          Ailish Byrne added a comment - not possible till we move to krad. this will need to be fixed another way. we certainly can't do something like this with a version of kfs that was supposed to be release 6 months ago.
          Hide
          Jonathan Keller added a comment -

          I feel like we are going in circles. The adapter from the validation pattern to the KRAD constraints was something that was worked on a few weeks ago. It needs to be done and for this release. We have 2,200 uses of validation patterns in KFS and we can not change them all right now and then regression test that we made the changes right.

          Show
          Jonathan Keller added a comment - I feel like we are going in circles. The adapter from the validation pattern to the KRAD constraints was something that was worked on a few weeks ago. It needs to be done and for this release. We have 2,200 uses of validation patterns in KFS and we can not change them all right now and then regression test that we made the changes right.
          Hide
          Peter Giles (Inactive) added a comment - - edited

          I don't believe there is an issue left to fix on this ticket. KFS is fine with (and in fact should be using) the KNS DictionaryValidationService. The key outcome here is that now those validations are being run.

          At Bryan and Muddu's request, I'm explaining why certain validation was being missed before when the KRAD DictionaryValidationService was being used. As mentioned, now that the KNS DictionaryValidationService is being used those validations are being run, which is why the issue with the PurchaseOrderDocument.statusChange validation was discovered. On save, the field has a value of "In Process" which doesn't get past the AnyCharacterValidation due to the whitespace. That has since been corrected in the KFS DD.

          Show
          Peter Giles (Inactive) added a comment - - edited I don't believe there is an issue left to fix on this ticket. KFS is fine with (and in fact should be using) the KNS DictionaryValidationService. The key outcome here is that now those validations are being run. At Bryan and Muddu's request, I'm explaining why certain validation was being missed before when the KRAD DictionaryValidationService was being used. As mentioned, now that the KNS DictionaryValidationService is being used those validations are being run, which is why the issue with the PurchaseOrderDocument.statusChange validation was discovered. On save, the field has a value of "In Process" which doesn't get past the AnyCharacterValidation due to the whitespace. That has since been corrected in the KFS DD.
          Hide
          Jonathan Keller added a comment -

          If that's the case then we may be OK as long as what is being validated when we use the KNS validation service is only the primitives on the business object and not the attributes for that business object as listed in the data dictionary.

          Show
          Jonathan Keller added a comment - If that's the case then we may be OK as long as what is being validated when we use the KNS validation service is only the primitives on the business object and not the attributes for that business object as listed in the data dictionary.
          Hide
          Peter Giles (Inactive) added a comment -

          Yes Jonathan, that is the case. To steal your description, the KNS DictionaryValidationService loops over the properties on the BO class.

          Show
          Peter Giles (Inactive) added a comment - Yes Jonathan, that is the case. To steal your description, the KNS DictionaryValidationService loops over the properties on the BO class.
          Hide
          Jessica Coltrin (Inactive) added a comment -

          closing all 2.1.2 Jiras

          Show
          Jessica Coltrin (Inactive) added a comment - closing all 2.1.2 Jiras

            People

            • Assignee:
              Peter Giles (Inactive)
              Reporter:
              Jonathan Keller
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel