Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

How to debug/troubshoot applications quickly

Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm building my first JavaEE web application using Glassfish and Netbeans. However, I'm finding it frustrating because I'm probably spending 90% of my time troubleshooting why it's not doing what I expect it to. Now I understand there is a learning curve but still it's frustrating.

Currently I try to initiate everything from unit tests, e.g. test-driven development. If/when I run into a problem I use netbeans "debug test file" feature to follow the flow of the problem. I'm wondering if there is a better way to troubleshoot issues?

Simply watching the output doesn't seem like enough. For example if an EJBcontainerException is thrown, well that could be anything you and you have to dig for the cause. Sometime the cause is shown in the stacktrace but other times I've had to use the debugger to dig in and find the problem. Nonetheless, all this is time consuming.

One huge time saver for me would be a way to keep the EJBContainer up and running. It currently takes about 30s to start, understandable considering it's an API of the glassfish server. But if there was a way to keep it up that would be nice.

Any advice on a better way?
Saloon Keeper
Posts: 22285
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First bit of advice is to choose your topic more carefully. There's nothing in your question related to JSF. If you ask questions in the wrong forum, you not only muddy the water there, you also aren't going to be getting the best support group. Although anyone can ask or answer questions anywhere (well, almost anywhere), we all have our places where we spend more time. For example, I don't usually drop in on the JavaScript forum.

There are some here who would chide you for depending on an IDE to learn complex Java technology. IDEs do so much for you that it's easy to create stuff that you have no idea of how it works and in the process, you can miss key concepts. And produce really horrible, flimsy apps, when you apply this to production work. I speak from personal experience, alas. While I don't really recommend using only Windows Notepad as an editor to learn with, you should avoid using "wizards" at least.

The quickest way to "debug" many application problems is to use a platform which automatically catches and reports errors before you start building on them. Java is outstanding in that regard, since a lot of things simply won't compile until you handle them properly. Conversely, the scripting languages that are so "productive" really aren't, because while they may get the UI up and running faster, they don't have any way to detect things like data type violations until you actually run the code. You haven't really become more productive, just shifted which point in the development cycle all the work has to be done in.

Unit test are definitely a booster. Often, however, they do require a little redesign in order to get full leverage. Unit tests usually run best and fastest when you separate the framework-dependent code from the framework-dependent code so that the unit tester is presented with a POJO. In cases when service calls must be made, a mock service can be much faster than actually invoking the real service.

It means our mission is in jeapordy! Quick, read this tiny ad!
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic