Beehive
  1. Beehive
  2. BEEHIVE-295

change button tag to prevent RuntimeException

    Details

    • Type: Wish Wish
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: NetUI
    • Labels:
      None
    • Environment:
      Beehive SVN / Tomcat 5.0.25

      Description

      If I use a button tag in a form to cancel and the action of that button points to an action that doesn't declare a form bean, I get a RuntimeException for every field in the form. The exceptions seem harmless, but I would rather not have the exception or have a single, specific exception.

      I will attach the stack trace that I got using the following code:

      — in the JSP
      <netui:button type="submit" value="submit"/>
      <netui:button action="cancel" type="submit" value="cancel"/>
      </netui:form></p>

      — in the controller
      @Jpf.SimpleAction( name="cancel", returnAction="newProductCancel" )
      }

      The obvious work-around (and probably correct use of the cancel action in this case) work fine, so this isn't recorded as a bug against Beehive.

      — the 'correct' controller code
      @Jpf.Action(
      forwards=

      { @Jpf.Forward(name="success", returnAction="newProductCancel") }

      ,
      useFormBean="newProductForm"
      )
      protected Forward cancel( NewProductForm newProductForm ) {
      return new Forward( "success" );
      }

      • jeremiah
      1. BEEHIVE-295.tar
        8.96 MB
        Jeremiah Johnson
      2. catalina.out
        108 kB
        Jeremiah Johnson
      3. log4j.xml
        1 kB
        Jeremiah Johnson
      4. newWebAppAndLogs.tar
        9.04 MB
        Jeremiah Johnson

        Activity

        Hide
        Eddie O'Neil added a comment -

        Not sure this is worth doing in the next few days...Moving to TBD.

        Show
        Eddie O'Neil added a comment - Not sure this is worth doing in the next few days...Moving to TBD.
        Hide
        Jeremiah Johnson added a comment -

        I attached newWebAppAndLogs.tar to demonstrate some things that I learned from Eddie about the form beans. That tarball contains four files: a new BEEHIVE-295.tar, cat.out.cancel, cat.out.nofax, and cat.out.withfax. It seems that my enhancement request may be getting into an area that can't be 'fixed'. The difference between cat.out.nofax and cat.out.withfax is most informational about this. Eddie can explain it better (and that information should get into some documentation), but the short answer is that all fields go to the expression evaluator for processing but the evaluator doesn't find a field matching something like

        {actionForm.fax} so it logs an ERROR and stack trace; however, the processing of the post isn't really broken because only fields in the form bean in use are required.

        In the demo application, I have two actions and each take a different form bean. Here are the form beans:
        public static class ContactForm extends FormData {
        private String name;
        private String phone;

        public static class LongerContactForm extends ContactForm {
        private String fax;

        Notice that the longer contact form just adds a new field to the existing contact form. Then, I have a form that is the union of all fields that I am interested in:
        <p><netui:form action="submitWithFax">
        Name: <netui:textBox dataSource="actionForm.name"/><br />
        Phone: <netui:textBox dataSource="actionForm.phone"/><br />
        Fax: <netui:textBox dataSource="actionForm.fax"/><br />
        <netui:button action="submitNoFax" type="submit" value="submit no fax"/>
        <netui:button type="submit" value="submit with fax"/>
        <netui:button action="cancel" type="submit" value="cancel"/>
        </netui:form></p>

        What I am doing is legal, but you can see errors logged. In fact, if I use the button marked 'submit no fax', then I get about 250 lines worth of ERROR logs even though the correct form bean is bound. The errors generated are simply the expression evaluator saying the it has some expression that it can't handle.

        I can understand the need for the log detail from the expression evaluator, but I think that error logs are too harsh. Perhaps an info message saying 'expression found "{actionForm.fax}

        " that doesn't map to any fields in the current form bean'?

        • jeremiah
        Show
        Jeremiah Johnson added a comment - I attached newWebAppAndLogs.tar to demonstrate some things that I learned from Eddie about the form beans. That tarball contains four files: a new BEEHIVE-295 .tar, cat.out.cancel, cat.out.nofax, and cat.out.withfax. It seems that my enhancement request may be getting into an area that can't be 'fixed'. The difference between cat.out.nofax and cat.out.withfax is most informational about this. Eddie can explain it better (and that information should get into some documentation), but the short answer is that all fields go to the expression evaluator for processing but the evaluator doesn't find a field matching something like {actionForm.fax} so it logs an ERROR and stack trace; however, the processing of the post isn't really broken because only fields in the form bean in use are required. In the demo application, I have two actions and each take a different form bean. Here are the form beans: public static class ContactForm extends FormData { private String name; private String phone; public static class LongerContactForm extends ContactForm { private String fax; Notice that the longer contact form just adds a new field to the existing contact form. Then, I have a form that is the union of all fields that I am interested in: <p><netui:form action="submitWithFax"> Name: <netui:textBox dataSource="actionForm.name"/><br /> Phone: <netui:textBox dataSource="actionForm.phone"/><br /> Fax: <netui:textBox dataSource="actionForm.fax"/><br /> <netui:button action="submitNoFax" type="submit" value="submit no fax"/> <netui:button type="submit" value="submit with fax"/> <netui:button action="cancel" type="submit" value="cancel"/> </netui:form></p> What I am doing is legal, but you can see errors logged. In fact, if I use the button marked 'submit no fax', then I get about 250 lines worth of ERROR logs even though the correct form bean is bound. The errors generated are simply the expression evaluator saying the it has some expression that it can't handle. I can understand the need for the log detail from the expression evaluator, but I think that error logs are too harsh. Perhaps an info message saying 'expression found "{actionForm.fax} " that doesn't map to any fields in the current form bean'? jeremiah
        Hide
        Rich Feit added a comment -

        I think it would be nice to have the ability to prevent processPopulate from doing anything on a per-button basis. Something like this (with a better name than 'ignoreFormInputs'):

        <netui:button action="cancel" type="submit" value="cancel" ignoreFormInputs="true"/>

        Struts has the 'cancel' attribute (to prevent validation), which is similar, but this seems more general to me.

        Show
        Rich Feit added a comment - I think it would be nice to have the ability to prevent processPopulate from doing anything on a per-button basis. Something like this (with a better name than 'ignoreFormInputs'): <netui:button action="cancel" type="submit" value="cancel" ignoreFormInputs="true"/> Struts has the 'cancel' attribute (to prevent validation), which is similar, but this seems more general to me.
        Hide
        Jeremiah Johnson added a comment -

        Here is a sample Web application that reproduces the output that I showed with the previous catalina.out. I am going to attach a new catalina.out that is consistent with this application. I created the new application because I wanted to ensure that my use of popups wasn't part of the cause of the exceptions I was seeing.

        $ tar xf BEEHIVE-295.tar
        $ cd BEEHIVE-295
        $ ant -f /home/jjohnson/projects/beehive/build/dist/apache-beehive-incubating-svn-snapshot/ant/webappRuntimeCore.xml -Dwebapp.dir=/home/jjohnson/projects/BEEHIVE-295 deploy.beehive.webapp.runtime
        $ ant -f /home/jjohnson/projects/beehive/build/dist/apache-beehive-incubating-svn-snapshot/ant/buildWebapp.xml -Dwebapp.dir=/home/jjohnson/projects/BEEHIVE-295 build
        $ jar cf BEEHIVE-295.war *
        $ mv BEEHIVE-295.war $CATALINA_HOME/webapps

        When the Web application is deployed, go to the appropriate URL (i.e. http://localhost:8080/BEEHIVE-295/) and click the cancel button. You should see the output with a couple RuntimeExceptions.

        • jeremiah
        Show
        Jeremiah Johnson added a comment - Here is a sample Web application that reproduces the output that I showed with the previous catalina.out. I am going to attach a new catalina.out that is consistent with this application. I created the new application because I wanted to ensure that my use of popups wasn't part of the cause of the exceptions I was seeing. $ tar xf BEEHIVE-295 .tar $ cd BEEHIVE-295 $ ant -f /home/jjohnson/projects/beehive/build/dist/apache-beehive-incubating-svn-snapshot/ant/webappRuntimeCore.xml -Dwebapp.dir=/home/jjohnson/projects/ BEEHIVE-295 deploy.beehive.webapp.runtime $ ant -f /home/jjohnson/projects/beehive/build/dist/apache-beehive-incubating-svn-snapshot/ant/buildWebapp.xml -Dwebapp.dir=/home/jjohnson/projects/ BEEHIVE-295 build $ jar cf BEEHIVE-295 .war * $ mv BEEHIVE-295 .war $CATALINA_HOME/webapps When the Web application is deployed, go to the appropriate URL (i.e. http://localhost:8080/BEEHIVE-295/ ) and click the cancel button. You should see the output with a couple RuntimeExceptions. jeremiah
        Hide
        Jeremiah Johnson added a comment -

        Here is the Log4J configuration file that I am using in my Web application.

        • jeremiah
        Show
        Jeremiah Johnson added a comment - Here is the Log4J configuration file that I am using in my Web application. jeremiah
        Hide
        Jeremiah Johnson added a comment -

        My example of the correct implementation was unnecessarily long. I should have used this in the example of what works:

        — a valid controller entry behind cancel
        @Jpf.SimpleAction( name="cancel", returnAction="newProductCancel",
        useFormBean="newProductForm" )

        The botton line is still the same, though: I don't want my cancel to use a form bean and I don't want a Runtime Exception if I don't specify useFormBean.

        • jeremiah
        Show
        Jeremiah Johnson added a comment - My example of the correct implementation was unnecessarily long. I should have used this in the example of what works: — a valid controller entry behind cancel @Jpf.SimpleAction( name="cancel", returnAction="newProductCancel", useFormBean="newProductForm" ) — The botton line is still the same, though: I don't want my cancel to use a form bean and I don't want a Runtime Exception if I don't specify useFormBean. jeremiah
        Hide
        Jeremiah Johnson added a comment -

        This is the portion of the Tomcat console output related to trying to use a simple action (or some action that doesn't take a form bean) as the target for a button in a form.

        • jeremiah
        Show
        Jeremiah Johnson added a comment - This is the portion of the Tomcat console output related to trying to use a simple action (or some action that doesn't take a form bean) as the target for a button in a form. jeremiah

          People

          • Assignee:
            Unassigned
            Reporter:
            Jeremiah Johnson
          • Votes:
            2 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development