Value Finders Bean Names

Question

Our custom value finders (UciDisbursementTypeValuesFinder) which override based (ex: DisbursementTypeValuesFinder) is getting an error in the document form rendering. " org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'uciDisbursementTypeValuesFinder' available "

Reviewing the stack trace in ActionFormUtilMap.java in kns shown recent changes (getKeyValueFinderBeanName) may be enforcing the defined spring bean name to match the name of java file and that it must be defined.

When it is an override of base valueFinders we generally create an extended class with Uci prefix to avoid confusion of base class while using the same spring bean name from base in order to have that change applied in KFS. Due to the above error, we had to specifically add bean alias to resolve this issue.

<alias alias="uciDisbursementTypeValuesFinder" name="disbursementTypeValuesFinder" />

Answer

Yep. This sucks but we’re kinda stuck with it for now. Sorry.

Some of the JSPs use some less-than-awesome ActionFormUtilMap code to instantiate a new instance of a value finder from a string name of the value finder class that is specified in the JSP. This behavior creates a problem for injection into value finders. For a variety of reasons, we want to be able to use injection with value finders. More spring injection and less instantiating classes from string names is the way of the future and JSPs and therefore ActionFormUtilMap usage is decreasing. So we updated the less-than-awesome code to use the unqualified class name as a bean name to pull the potentially injected value finder from the context.

Does that create a situation where we may need to create some bean aliases?
Yep. But only for value finders that need to accessed via ActionFormUtilMap which should be limited to value finders that are referenced from transactional documents. This should not affect the bean name of every value finder.

Will this be a permanent thing?
No. None of the new API/service driven code is relying on ActionFormUtilMap or the problematic pattern of instantiating classes from string names.

Will it be here for a while?
Most likely. Until we complete the migration away from JSPs and ActionFormUtilMap, we will have this inconvenience. While we are actively working on this migration, it will take a significant amount of time to fully accomplish it. We share in the inconvenience of this as it affects our Stevens overlay and soon our CSU overlay.
I do apologize for not communicating about this potential impact when the decision was made. I take ownership of that communication failure and will work to do better in the future.