Announcement Announcement Module
Collapse
No announcement yet.
Handling errors with discretion Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Handling errors with discretion

    Hello,

    I noticed that exceptions bubble up to the user interface without any discretion. While its acceptable while doing development, its unacceptable for production systems, especially when that site is public facing. This may very well reveal information one doesn't want other people in the public to see. This is rather serious.

    Consider a java class that has a few native methods implemented with JNI. When the native library isn't found when working with the entity, the validation of the form fails with an error message "Property contents threw exception; nested exception is java.lang.NoClassDefFoundError: Could not initialize class com.example.NativeClass". This is at no fault to the user and should actually result in a 500 error.

    Can Roo generate applications that handle errors with more discretion?

    Thanks,
    Werner

  • #2
    Handling errors with discretion

    I'd also like to suggest that the stack trace etc belongs in a log, not the user interface. Data access errors should be totally shielded from the user as they can take no action.

    You should never tell the public why the system failed if they were not at fault. Doing so when that user was a hacker and wishing you harm, you may very well confirm a weakness and promote further exploitation.

    Comment


    • #3
      My preferred model to be honest is to log it via the system's normal logging API but insert a UUID into the text and display that "reference code" to the user. As such the operations folks can find the UUID easy with a text search should the user report the issue, plus the log levels and destinations can be easily reconfigured to output to a file, syslog server, monitoring system etc. Might be worth logging this as an enhancement request in Jira if anyone agrees with me and/or have their own ideas on how they would like to see errors tracked and reported.

      Comment


      • #4
        Hi Werner,

        Exception handling is configured in the WEB-INF/spring/webmvc-config.xml application context by default. So if you would like to change exception handling in your application when moving from development/testing to production you can adjust the SimpleMappingExceptionResolver configuration to suit your needs.

        We believe the primary goal for the Roo scaffolded views is that that they are supporting the development of backend admin interfaces. This takes a similar view on things compared to what rails, django, grails, etc frameworks do. Many of the default functionalities (delete, update, etc) the scaffolding exposes would not be desirable in public facing web UIs anyway.

        Also, we have had a number of very positive remarks about the Roo exception handling in the web UI given that it does not leave you with a ugly 500 default error page (including stack trace) in Tomcat or other containers. As you know by default, the message panes are collapsed so the user is not confronted with them unless he wants to.

        I do agree that in production systems you would not want to present this level of detail though. It is easy for you to change the relevant jspx files accordingly so you can present whatever you think is appropriate. Roo will not overwrite any of the changes made in dataAccessFailure.jspx, resourceNotFound.jspx, or uncaughtException.jspx. Of course you can merge them into a single error document if you wish.

        The logging support offered by Roo ensures that all exceptions / errors are also written into logs.

        HTH,
        Stefan

        Comment


        • #5
          Handling errors with discretion

          Thanks Stefan,

          I have no problem with the behavior when running in development. The more information the better. I just don't approve how it behaves in production. Changing the configuration files each time I switch environments just leads to mistakes and complicates deployment.

          Lets look at rails for a second. It uses the RAILS_ENV environment variable to know under which environment (production, development, test) its running. The configuration files for each environment contains the settings to deal with caching, error handling, logging and so forth. No modifications to the application are really required when switching between from development to testing to production. It keeps it simple and avoid mistakes.

          I believe Roo should generate applications that are aware of the environment they are running in. When one specifies -DMYAPP_ENV=production when running tomcat, then the system will behave in a production mode which is more optimal, secure and so forth. This should satisfy my need.

          I don't agree that Roo scaffolding is only useful for backend systems. The generated infrastructure is the single largest benefit of Roo. I don't like the final markup, but heck the rest works just great. Why impose such a limit?

          I don't see some data access errors or java.lang.NoClassDefFoundError in the logs, even when the logging level is INFO. So I guess it isn't really working as advertised.

          Thanks,
          Werner

          Comment


          • #6
            Hi Werner,

            I think the idea of switching to a setting which is more appropriate for production use is a good idea. I am sure there are more things that can be adjusted other than just exception handling. Please go ahead and open a Jira ticket and feel free to suggest what should be changed between a development setting and a production setting.

            As for the logging, have you tried setting debug for all logging?

            Cheers,
            Stefan

            Comment


            • #7
              I created ROO-629 requesting that ROO applications be "environment" aware.

              Comment


              • #8
                Originally posted by Stefan Schmidt View Post
                As for the logging, have you tried setting debug for all logging?
                Nothing appears in the debug log related to the issue.

                To reproduce, create a Java class with a native implementation (NativeImpl). When calling System.load, or System.loadLibrary, point it to a bogus location. On an entity, create a field "contents", with a getter and setter. In the setter, create an instance of "NativeImpl" and call the native method before setting the field.

                A validation error is displayed for "contents" with a message that the library couldn't be found. Depending on whether you call System.load or System.loadLibrary, different errors will be shown.

                Regards,
                Werner

                Comment

                Working...
                X