Announcement Announcement Module
Collapse
No announcement yet.
[JSF/SWF} DispatchMethodInvoker is null Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • [JSF/SWF} DispatchMethodInvoker is null

    Hello

    I am been trying to add a spring validator into my jsf implementation but the following exception is thrown after submit:

    Code:
    17:57:28,953 INFO  [HtmlRenderKitImpl] Overwriting renderer with family = javax.faces.Command rendererType = javax.faces.Link renderer class = org.apache.shale.renderer.ValidatorCommandRenderer
    17:59:03,468 ERROR [[/websara]] Exception thrown executing [AnnotatedAction@1cf701c targetAction = com.xxxx.eets.app.tag.flow.TagFlowFormActionDelegate@167e563, attributes = map['method' -> 'validate', 'validatorMethod' -> 'validateTagCode']] in state 'enterTagDetails.view' of flow 'tag-main-flow' -- action execution attributes were 'map['method' -> 'validate', 'validatorMethod' -> 'validateTagCode']'; nested exception is java.lang.NullPointerException
    org.springframework.webflow.engine.ActionExecutionException: Exception thrown executing [AnnotatedAction@1cf701c targetAction = com.xxxx.eets.app.tag.flow.TagFlowFormActionDelegate@167e563, attributes = map['method' -> 'validate', 'validatorMethod' -> 'validateTagCode']] in state 'enterTagDetails.view' of flow 'tag-main-flow' -- action execution attributes were 'map['method' -> 'validate', 'validatorMethod' -> 'validateTagCode']'; nested exception is java.lang.NullPointerException
    Caused by: 
    java.lang.NullPointerException
    	at org.springframework.webflow.action.FormAction.invokeValidatorMethod(FormAction.java:805)
    	at org.springframework.webflow.action.FormAction.doValidate(FormAction.java:932)
    	at org.springframework.webflow.action.FormAction.validate(FormAction.java:640)
    After stepping through the code I have found that the validateMethodInvoker is null.

    Code:
    /**
     * Returns a dispatcher to invoke validation methods. Subclasses could
     * override this to return a custom dispatcher.
     */
    protected DispatchMethodInvoker getValidateMethodInvoker() {
      return validateMethodInvoker;
    }
    I have run the sellitem-jsf example successfully so there's obviously something odd in how I am configuring this.

    Code:
    <bean 
    	name="tagViewController" 
    	class="com.xxx.eets.app.tag.flow.TagFlowViewController"
    	scope="prototype"/>
    
    <bean 
    	id="tagFormAction" 
    	class="com.xxx.eets.app.tag.flow.TagFlowFormActionDelegate">
    	<property name="formObjectName" value="tagViewController" />
    	<property name="formObjectClass" value="com.xxx.eets.app.tag.flow.TagFlowViewController" />
    	<property name="formObjectScope" value="FLOW" />
    	<property name="validator">
    		<bean class="com.xxx.eets.app.tag.validator.TagMainValidator" />
    	</property>	
    	<property name="userService" ref="userServiceTxnl"/>
    	<property name="searchUserFlowHandler" ref="searchUserFlowHandler"/>
    	<property name="searchAccountFlowHandler" ref="searchAccountFlowHandler"/>
    	<property name="saveTagFlowHandler" ref="saveTagFlowHandler"/>
    </bean>
    Code:
    <transition on="submit" to="manageUsers.view">
      <action bean="tagFormAction" method="validate">
        <attribute name="validatorMethod" value="validateTagCode" />
      </action>
    </transition>
    Any advice would be appreciated.

    regards JC.

  • #2
    Hi JC, do you see any other exceptions earlier in the log? For example if the validator does not support the form object class.

    Since you have stepped through the code see FormAction's initAction() method. That's the method initializing the validateMethodInvoker when the application context is loaded.

    Ross

    Comment


    • #3
      Hi

      The operation initAction is never reach by the time the NPE is thrown as described. This would explain the NPE at least.

      Code:
      protected void initAction() {
        if (getValidator() != null) {
          Assert.notNull(getFormObjectClass(), "When using a validator, the form object class is required");
          if (!getValidator().supports(getFormObjectClass())) {
            throw new IllegalArgumentException("Validator [" + getValidator()
      				+ "] does not support form object class [" + getFormObjectClass() + "]");
          }
         // signature: public void ${validateMethodName}(${formObjectClass}, Errors)
         validateMethodInvoker = new DispatchMethodInvoker(validator, new Class[] { getFormObjectClass(),Errors.class });
        }
      }
      No earlier exceptions.

      Thoughts?
      Last edited by jamesclinton; Feb 21st, 2007, 01:50 AM.

      Comment


      • #4
        I've solved the validation problem by calling the initAction 'hook' method myself.

        The method is described as follows:

        void org.springframework.webflow.action.FormAction.init Action()
        Action initializing callback, may be overriden by subclasses to perform custom initialization logic.

        Keep in mind that this hook will only be invoked when this action is deployed in a Spring application context since it uses the Spring InitializingBean mechanism to trigger action initialisation.
        My findings suggest a possible bug because the hook method isnt being called - however the sellitem-jsf example proves otherwise.
        Last edited by jamesclinton; Feb 21st, 2007, 02:13 AM.

        Comment


        • #5
          Hm, initAction should be invoked as long as the FormAction bean is loaded through a Spring context. I'm assuming your context (the one containing FormAction) is loaded from web.xml as in sellitem-jsf:

          Code:
          <context-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>
                classpath:org/springframework/webflow/samples/sellitem/services-config.xml
                /WEB-INF/webflow-config.xml
            </param-value>
          </context-param>
          JC, also something else I just noticed. What is the tagViewController "prototype" bean just above the FormAction bean in your context? In sellitem-jsf the delegation to WebFlow is done through a FlowRegistry bean with id "flowDefinitionLocator". There is no controller.

          Ross

          Comment


          • #6
            I'm assuming your context (the one containing FormAction) is loaded from web.xml as in sellitem-jsf:
            Code:
            <context-param>
            	<param-name>contextConfigLocation</param-name>
            	<param-value>
            		classpath:spring/appCtx-persist-hibn8MappingFiles.xml
            		classpath:spring/appCtx-persist-cacheStrategies.xml
            		classpath:spring/appCtx-xxx-flow-handlers.xml
            		classpath:spring/appCtx-xxx-datagateway.xml
            		classpath:spring/appCtx-service-validators.xml			
            		classpath:spring/appCtx-xxx-security.xml
            		classpath:spring/appCtx-xxx-actions.xml
            		classpath:spring/appCtx-xxx-config.xml
            		classpath:spring/appCtx-persist-dao.xml
            		classpath:spring/appCtx-service.xml			
            	</param-value>
            </context-param>
            JC, also something else I just noticed. What is the tagViewController "prototype" bean just above the FormAction bean in your context? In sellitem-jsf the delegation to WebFlow is done through a FlowRegistry bean with id "flowDefinitionLocator". There is no controller.
            tagViewController is the backing bean for a paritcular flow. It plays exactly the same role as Sale in sellitem-jsf , holding entities and event listener hooks etc..but also behavies like the 'Shale View Controller' from apache. Hence the naming convention adopted.

            regards

            JC
            Last edited by jamesclinton; Feb 21st, 2007, 11:12 AM.

            Comment


            • #7
              The only difference in my implementation to the sellitem-jsf is the fact that I have extended FormAction and use this class as a delegate between the backing bean and other services. This form action bascially manages the entire flow and allows me to keep my backing bean slim as they can get pretty huge when using wizards..
              Last edited by jamesclinton; Feb 21st, 2007, 11:40 AM.

              Comment


              • #8
                Was this problem ever solved (other than by manually invoking the FormAction.initAction() method, which is clearly not the intended use). I'm having exactly the same problem, using Spring webflow 1.0.5
                I also extend the FormAction class with my controller, but the initAction() method is never getting called.
                Anyone got any thoughts?

                Comment


                • #9
                  I also had this problem, and tracked it down. It turns out that (at least in my case), the Action class (a subclass of FormAction) was implementing the afterPropertiesSet() method, but it did not call super.afterPropertiesSet().

                  This override prevented the afterPropertiesSet method in AbstractAction from calling the initAction in FormAction, which was identified correctly above as being necessary to set the validateMethodInvoker property.

                  I hope that this helps.

                  Comment

                  Working...
                  X