Home/ Questions/Q 7668159
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T15:17:22+00:00

Is there a way of debugging JSF + PrimeFaces applications by simply looking at

  • 0

Is there a way of debugging JSF + PrimeFaces applications by simply looking at one log file? To be more specific, here is how I personally do it at the moment if something doesn’t work as expected:

  1. Look for visual indicator on the Web page (e.g. if I receive HTTP 500 obviously something is wrong)
  2. I look in the log file of my application server for any warnings, errors or stacktraces
  3. I look in the Firebug’s network console to see if there were any errors in the HTTP response; this tends to happen from time to time (and it’s not shown in the log!)
  4. I check if it is a validation error by including a p:message on the form and display it.

For me, checking for errors is a 4-step workflow. Is there a better way of doing this? Ideally, it would be great if all these errors could be logged to a single log. Is this DIY or there is some standard way of doing it?

Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There is nothing out of box that will give you what you describe because these are all situations that occur on different layers.

    1. This is typically because an unhandled exception made its way up the call stack. If you improve your code for exception handling then these circumstances should be caught and logged.

    2. Improved exception handling and logging at all application layers will help capture all errors and exceptions in a single log file on the application server.

    3. Firebug catches network errors in asynchronous postbacks as well as Javascript exceptions. This is completely a client side concern as the server just derives the markup. It might be possible to catch all Javascript exceptions before they are propagated up to Firebug and to send an asynchronous error report to the server for the server to log. This shouldn’t be too terribly difficult to implement.

    4. Again, better logging in your validator methods will be able to put this information in the application server logs so that you have all of this information in one place.

    The bottom line is that these are all situations where they become a non-issue for developers who learn how to intuitively include good Instrumentation code throughout their applications.

    • 0