Skip to end of metadata
Go to start of metadata
Icon

As I find them, this page will list the questions raised / issues found during the Rice conversion of the KFS application.

Type Inconsistency in MaintenanceDocumentBase causing exceptions

Getter: org.kuali.rice.kns.maintenance.Maintainable getNewMaintainableObject()
Setter: void setNewMaintainableObject(org.kuali.rice.krad.maintenance.Maintainable)

Icon

  Scott is taking care of fixing this.

MaintenanceDocumentAttributeValueReader is not handling nested object properties

In the code below, the property was projectManagerUniversal.principalName - but it is attempting to pull "principalName" from the ProjectCode object.

Upon Submit of a Project Code Maintenance Document

API call to retrieve child document types removed

Some KFS functions need to be able to look at the document type hierarchy. I can not find a (public) API call to retrieve this information. The DocumentType DTO object does not contain this information. Nor does there seem to be a way to retrieve all documents types under a given parent through the public APIs.

In the KFS case, the call is expecting to retrieve the entire list of child documents. (I.e., multiple levels of children) I would prefer that this call be provided by the Rice APIs, but I could make the recursive calls within KFS, it will just be a bit slower as it will take multiple service calls.

Icon

I did find an service call which would do it, but it's internal to KEW and should not be used by client applications. Functionality like this needs to be exposed via the public DocumentTypeService.

KEWServiceLocator.getDocumentTypeService().find(documentType, fieldValues.get("parentDocType.name"), descend);

Unable to replace document header class

KFS has the need to override DocumentHeader with a subclass. This ability was there in the Rice 1.0.x line. There is a documentHeaderClass stored on the DocumentHeaderDao. However, the line below appears in the DocumentBase class which sets the header on the document.

KRADServiceLocatorWeb.getDocumentHeaderService().getDocumentHeaderBaseClass()

Since this pulls from the internal GRL for the KRAD module, I don't see a way to override the documentHeaderService. I have the bean defined in my KFS context, but the call above is not using it. HELP!

Icon

Note sure I see the problem.

If you want to globally set the document header class, you can override the documentHeaderDao bean to set the document header class.

To override in certain cases, set the document header class in the document subclass constructor.

Am I missing something?

Icon

Actually, it is more insidious than I thought...

After tracing the logic (I attempted to ensure that the KFS context was first in the GRL instead of last and I was still having the problem.), I found that the documentHeaderService IS being loaded correctly.

HOWEVER the DocumentServiceImpl has the RICE instance of the document service injected through Spring. And that still has the old DAO.

The practical effect of this is that, for any service which KFS wants/needs to override, we need to check for EVERY other location into which Rice is injecting it and also copy those bean definitions into KFS so that we can inject our copy of the service. (And then every service into which those are injected...and so on...)

This is not a feasible solution and is extremely prone to errors like this one where overrides which we rely on are effectively ignored depending on how the Rice Spring files are configured.

It turns out the below is required to ensure that all code sees the KFS versions of the services first.

Init Code to insert KFS as the top-level loader
For Reference - the code below is needed to override all services related to the document type DAO

Moving away from EBOs causing problems

As part of the conversion, we are attempting to reduce the usage of EBOs and move to use of the Rice services for items like Campus, PostalCode, State, and Country. Unfortunately, this has side-effects related to the DD. The relationships section of the business object entry requires the target class to inherit from BusinessObject. Since KFS is now using the "dto" versions of these objects, this results in startup validation errors. KFS will have to remove the relationships to these rice objects or revert to the use of EBO classes. Is there a reason that the relationship definitions still use BusinessObject?

My current workaround (I don't know how far it will work before it breaks down.) is to override the RelationshipDefinition with one which changes the apparent class (E.g., converts from Campus to CampusEBO) in the definition. I don't like it, but it has allowed us to proceed.

Icon

We should look into dropping this restriction. We want need the support for general data objects. I will enter a Jira for this.

Access Security Module

The access security module was created with the assumption that permission and role names would match. Since permission names need to be unique under Rice 2.0, this entire module needs to be revisited.

Icon

If I remember correctly, the permissions are created using the definition name, and one for each restriction type (template). Can we:

1) Require the definition to be unique (this is possibly already the case)
2) Add a standard suffix for each type:
(definition name) + ' - lookup'
(definition name) + ' - inquiry'

Method Cache

What is replacing the method cache? We have some code (mainly in unit tests) which needs to flush the caches. They reference the removed class: GeneralCacheAdministrator

We also have @Cached and @CacheNoCopy annotations throughout the code. These are critical to system performance. Will they still be used? Or do we need to do something else for caching now?

(Actually, I notice now that the @Cached annotation we use is gone. Does it have a replacement?)

Icon

The previous Rice caching infrastructure has been replaced by Spring 3.1 caching abstraction. For documentation see:
https://wiki.kuali.org/display/KULRICE/Rice+2.0+-+Compatibility+Refactoring+-+Caching+Infrastructure

Basically, to setup local caching a cache manager will need to be created for the KFS, and then you can use the built in Spring annotations. The page above documents all of this.

DelegateMemberCompleteInfo / RoleMemberCompleteInfo / RoleResponsibilityActionInfo

These classes are used by the Org review maintenance document in KFS, but I can not find an equivalent which contains all the needed information.

Icon

Jeremy was working with Jonathan on getting the needed functionality. Anything remaining on this one?

RESOLVED - Access to PersistenceBroker in preUpdate/postInsert/etc.. methods

With the new methods used for the ORM hooks that are not OJB-specific, the persistence broker is not passed in. Some of the uses of these methods do access the database. What is the method we should use to obtain the current persistence broker in these methods?

Icon

Use the spring provided OjbFactoryUtils class which has method getPersistenceBroker (PBKey key, false). Construct the PBKey argument using the JCD alias, and pass in false for the second argument stating a new persistence broker should not be created.

For information on why this was reworked, see:
https://wiki.kuali.org/display/KULRICE/Rice+2.0+-+KNS+Notes+Modularity+Refactoring+Proposal

New Configuration Method

KFSApplicationConfigurationServiceImpl will need to be re-implemented since these services have been refactored.

Icon

Anything needed from us on this one?

RESOLVED - New Startup Method

The RiceConfigurer class is gone. How do we bootstrap the application now?

Icon

Each module still has its own configurer, just the top level RiceConfigurer was removed. So instead of overridding the Riceconfigurer, each module configurer will need to be overridden. Does that help?

REFACTOR IN KFS - WebConstantsInitListener and JSTLConstants

The latter of the above does not exist in Rice 2.0. KFS was using the ability to use instances of the constant classes extensively in the web tier. KFS is likely to have significant regressions where it was depending on any of the constants which were in the RiceConstants or KNSConstants classes.

Icon

The constants are now exported using spring.

First, setup a new bean like the following:

<bean id="KRADConstants" class="org.kuali.rice.core.api.util.collect.ConstantsMap">
<property name="constantClass" value="org.kuali.rice.krad.util.KRADConstants"/>
</bean>

where the value of 'constantClass' is the class containing the constants you want to export.

Then configure the constants export using the following bean:

<bean class="org.springframework.web.context.support.ServletContextAttributeExporter">
<property name="attributes">
<map>
<entry key="KRADConstants" value-ref="KRADConstants"/>
</map>
</property>
</bean>

COMPLETE - COMPONENT and NAMESPACE Annotations

Where are they? KFS and some implementors depended on that function of the ParameterServiceBase to be able to override the component information for parameters while being able to use the customized class names.

Icon

They still exist but were moved to ParameterConstants as inner beans (which is not a great place for them)!

Manually Attaching Notes to Documents

document.getDocumentHeader() is no longer a BO. So the NoteService attachment does not work.

Icon

Not quite following this issue. DocumentHeader is still a BO, and the NoteService should still work. The notes were refactored a bit to change dependencies, but all previous functionality is still supported.

For information on the refactoring, see https://wiki.kuali.org/display/KULRICE/Rice+2.0+-+KNS+Notes+Modularity+Refactoring+Proposal

Processing Document Search Results

  • DocumentSearchResultRowDTO does not seem to have a parallel like some of the other document search DTOs.
  • What has replaced DocumentSearchContext?
Icon

DocumentSearchContext is not necessary anymore. Before it was needed by extractDocumentAttributes but now this method receives the Document instance. In other places the DocumentSearchContext was getting passed around, only the document type name was needed, so those method were refactored to just pass the document type name.

DocumentSearchResultRowDTO is now just DocumentSearchResult

Parameter Lookups

KFS in a couple places looks for all parameters which match a pattern. There does not seem to be an API for this on the new ParameterService. How will we retrieve these in Rice 2.0?

Icon

ParameterRepositoryService contains method ParameterRepositoryService which will allow this. ParameterService should be a facade to the repository service so we will add this method there as well.

Linking to lookups

We have some places in the code which are building their own parameters for lookup links. There has got to be a better way to do this. And, the "BO" used for the document search is no longer present. I wonder if the code below ever worked when the Rice server was separated...

Icon

The new BO to pass is org.kuali.rice.kew.impl.document.search.DocumentSearchCriteriaBo.

KIM Role Service Missing sortRoleMembers

KFS depends on being able to sort the role members so that organization hierarchy is respected when routing. Is there an alternate for this function?

Icon

A jira was created to add this method : https://jira.kuali.org/browse/KULRICE-6008

  • No labels