Wednesday, January 31, 2007

Troubleshooting Insight

Yesterday, sir explained us how to develop a web application using Struts and provided us with requirements specification for one. We had to use Eclipse 3.2 with wtp and Struts 1.2.9 for that. Avoiding use of plug-ins such as Easy Struts was the constraint.

We worked on the given problem definition just to realize the difference between theoretical knowledge and its implementation. More often that not developers are given training on how to build a project in certain environment. This means that during training some development environment (i.e. configuration files, build files, directory structure specific to that environment etc.) is assumed which is working. The training is given about how to use and develop applications on top of that.

Today sir asked whether we have done with it? Nobody was done. He asked, "where did you stuck up? Tell me the exact points." Then we individually started telling what problem we faced. He listened to our problems. It was to investigate which approach we took, what troubleshooting we did, etc.

Troubleshooting is indispensable to all developers. It is a critical aspect of development.
And today we learnt how to troubleshoot our applications.

Sir explained that plug-ins are automation tools and should be used only when needed i.e. when productivity is of prime importance. During learning use of automation tools is highly discouraged because, we must know what errors arise, why do they arise, how to troubleshoot them, and finally how to make it work.

There was an XDoclet error in web.xml, then there was some confusion regarding contents of web.xml and struts-config.xml, tld files etc.

Yesterday he explained building applications using Struts in following steps.

  • Create Struts Environment

  • Write Struts Code

  • Deploy


Sir started from scratch. He asked whether we all had struts.jar in lib folder, whether it is in the classpath of the project, whether we got Eclipse intelli-sense help after including struts.jar from Eclipse.

This investigation concluded that the problems were not because of struts.jar.

Then he proceeded on to the configuration files: web.xml, struts-config.xml. There is one mapping in web.xml which is responsible to call ActionServlet class of Struts framework. Sir suggested, "if you copied some web.xml that configures more than bare minimum functionality and you are screwed up, do remove all tags that are not required i.e. tags other than "must have" tags for application to run. Just don't follow things around blindly. Focus on one thing at a time. Go step-by-step. So, you know exactly at which step you are stuck up. Know exactly what and why you are doing it this way.

Unless application runs, errors and exceptions give us insight of the problem. So, they must be there and we should closely observe them to better understand working of tools and technologies we use. They are not bad !

Further, now-a-days every modern tool provide us with logs of its execution. Again spending 'good' time with them enriches our insight and experience.

Suppose you can not locate cause of error, try to revert to the 'last known working state' and then go on adding things to it, every time checking whether it is running or screwed up."


Kalyani Alshi, Nagpur.

No comments: