Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.

Logging or Debugging? Have both with XRebel 3.2.0

We’re excited to announce the release of XRebel 3.2.0! In addition to UI improvements and enhanced framework support, we are introducing a brand new feature – the logs view.

It makes finding the relevant logs a breeze, even when using trace level logging and AJAX-heavy single page apps. We didn’t stop there. When you log an object — such as ShoppingCart — we will display it like a debugger would, as an expandable object tree!

Free XRebel Trial Download Just gimme the zip!

In addition to the Logs view we made some UI improvements. HTTP requests now stick to the top when scrolling:

We improved date formatting in SQL:

We also improved integrations with frameworks:

  • Added support for Spark Framework 2.4.
  • Improved support for exceptions in the MongoDB 3 driver.

Logging vs. remote debugging: Why not get the best of both worlds?

Every webapp in development holds a great supply of surprises for the developer. When something is behaving unexpectedly, there are two ways to troubleshoot it: either add debug logging or attach a remote debugger. Both have their pros and cons. However, why settle for a trade-off when you could get the best of both worlds?

Logging is the simplest form of troubleshooting. Just add some System.out.println statements and you’re ready to go. In addition to being super easy to use, it does not demand attention. You can click around and collect the logs later. Debug logging also excels in comparing application state. For example, you can print out an array before and after calling a function. None of this is available with remote debugging.

Logging does have its limits however. When adding a lot of statements, the results keep growing. Especially in AJAX-heavy apps. Good luck finding the info quickly and easily. Another major limitation is logging objects. While it is easy to write a string or a number, emitting an array or a ShoppingCart is not. The default output is useless and you will have to implement toString() on all the classes. After all that effort, the result is only usable for small objects. Anything beefier will result in a wall of text. That’s where remote debugging comes in.

With remote debugging you can easily browse an object tree and step through the program execution, line by line. For the latter, remote debugging is irreplaceable and well worth the recommendation. If it’s the former you’re after, you are also in for some major inconveniences. For starters, it’s hard to set up. Can you do it for Tomcat without Googling? Probably not. Also, it demands breakpoints, which keeps stealing focus, regardless of whether the problem occurs or not. When you finally manage to hit the breakpoint at the correct time, you can only view one state at a time. Want to print an array before and after calling a function? No such luck.

Which is the lesser of the two evils? What compromises are you willing to make? If only there was a way to get the best of both worlds. Now there is.

XRebel 3.2.0 comes with the Logs view. It only shows the log statements that were emitted during a request. This makes finding the relevant info much easier — even when using trace level logging. This scales particularly well with AJAX-heavy single page apps, because logs for every request are displayed separately.

I am particularly proud of the object tree support in the Logs view. When you log an object — such as ShoppingCart — we will display it like a debugger would, as an expandable object tree!

No breakpoints or googling required. It works beautifully with your business objects and has even better support for arrays, collections and maps. You also keep the ability to compare an object (before and after). Think of all the toString() functions you can delete! I have always found deleting code very satisfying. You should try it.

The Logs view is the newest addition to XRebel’s issue-finding capabilities. In the Application view you can find the slowest parts of your code in less than two minutes, without needing a PhD in profiling. Again — we connect the trace with the request so that the context is always there. Chances are that the methods are slow because they are accessing a database. That is why we include IO operations with the profiling results. This way you will know when the trouble lies with internets and not with the the algorithm.

Once IO has been established as the scapegoat, the reason could be as simple as making too many database queries. When Hibernate gets misconfigured, Spring’s petclinic demo application easily makes over 30 database queries to display a list of 10 pet owners. They accomplished this great feat of de-engineering by making a separate database query for every row in the first one. This is what we call an N+1 problem. XRebel finds these with ease. These issues are hard to detect early because sample data is small and developers are using an in-memory database during development. In contrast, a production environment where the database contains much more than 10 rows is accessed over a network.

XRebel gives real-time insight to webapps and helps you fix the issues just as fast. If you are not convinced, get the trial. It’s free and no credit card information is required. Let us know which features you found most useful.

Taste XRebel 3.2.0

Arnel Pällo
XRebel product manager