Current Topic: 4.3.4.Troubleshooting Problems and Debugging Code in Web Applications
You have a privilege to create a quiz (QnA) related to this subject and obtain creativity score...
4.3.4.Troubleshooting – Debugging of Web Applications
Increasing a number of elements in a system will increase the chance that something goes wrong.
And when something goes wrong this cheat-sheet with the Troubleshooting hints might be very helpful.
The main areas of troubleshooting:
Check Eclipse Problems - Window – Show View – Other - Problems
Check Eclipse Compiler and Project Facets – should reflect the Java version that you intended to use.
Check the option: Project - Build Automatically -----------------------------------------------------
Tomcat: Check Deploy Path
Check all components publishing at the Deploy Path
-----------------------------------------------------
Tomcat Server: Start in Debug – Add Breakpoints, open a browser and navigate to a proper page and proper controls
--------------------------------------------------------
Communicate with your mentor, friends, or/and user groups.
Express clearly what happens, provide screen shots, code and console outputs.
Compress your project sources in a single file (relevant sources only!)
Go to Eclipse menu at the top. Select Show View – Other – General – Problems Then look at the problems that will appear at the bottom of the screen.
Maximize, read, understand, and fix those that related to your project.
When have time – fix all !!!
Check Java Compiler Version set by Eclipse to your new project. It is possible that Eclipse default setting is not the Java version that you intended to use. Fix it and remove some (maybe all!) problems from the list.
Check the settings for the Project Facets and fix if necessary to the Java version, which is installed and you plan to use.
Check the Project – Build Automatically option. This option makes Eclipse compile your sources each time you change them. Otherwise, you might change the source, but Eclipse will keep the same old compiled class file and you might be surprised by no changes in the application behavior.
If you introduce a lot of changes at once, it might be wise to keep this option off till you finish entering the code. This will prevent Eclipse reacting to any keystroke by a new attempt to a new compilation, which can be very annoying.
Check Tomcat – Deploy path. We recommend to set the deploy path to {tomcat}/webapps directory, the same place, where Tomcat would run the applications, if started from the command line. So, in both cases the deploy path for Eclipse would be the same. You would have an opportunity to start Tomcat from the command line and compare server and application behavior.
Check If all components are published. You assume that the web application is published. But sometimes this assumption needs to be proved right or wrong.
Go to c:\tomcat7\webapps (Assuming that the Tomcat is installed at c:\tomcat7 - directory) and check ALL your project components. Also take a look at the date and time of update of the components. To simplify the debugging process make sure that only one project is in the webapps - directory.
Was it clear so far?
You might need to delete tomcat7/temp and tomcat7/work directories, which keep server side cache.
There are cases when the Tomcat server configuration in Eclipse is getting corrupted and your attempts to publish an application are failed.
In this case the easy fix is to Delete the Tomcat Server configuration and create a new one. Do not forget to change the Deploy Path and if necessary change the HTTP Port from 8080 (default) to for example, 80, or 81.
You change the port when you have another application, which is running on the port 8080. For example, Oracle Express includes the web application, which might be running on this port. If you change the port to port 80, the URL to your application will be easier, you do not need to specify the port. Port 80 is the default port for web applications.
For example, http://localhost/BASE (the application BASE is running on port 80) versus http://localhost:81/BASE.
Finally, the web application is running in the Tomcat server. We can start the process of troubleshooting the problems, if any. With Eclipse, we can debug our code by debugging our code run-time, creating breakpoints, and looking at the variable values, uncovering and fixing unpleasant surprises.
1. Where do you start? - If we debug a Java Application we do right mouse click on the source with the main() and Run As Java Application.
In our case, when we debug a web application, we need to start Tomcat Server and use a browser to navigate to our pages and our controls and check the application behavior.
So, the first step is to identify the problem. Usually, you would see the problem on the web page and you would also see a problem in the Eclipse Console. If you see a red line that ends with the link to your source, this is a good starting place.
What is the next step?
2. Click on the first error link in your source and create a breakpoint near that line (in the illustration above, the line 79)
What is the next step?
3. Now Stop the server and Start Server in Debug.
This would allow you to use the same web page navigation and controls to get to the same source that caused the problem. This time Eclipse will stop execution in the breakpoint and you will be able to walk through the code line by line (F6) or run code till the next breakpoint (F8).
4. Watch the values of variables. This might help you uncover unexpected surprises. You can move mouse over a variable in the source to see the value or just look at the right-top Variables panel.
Assignments:
1. Create 3 QnAs to the content, use WordPad, and email to dean@ituniversity.us as a text file 4.3.4.QnA.Your.Name.txt
2. Copy and Modify the previous Dynamic Web Project project, change the HTTP Port, and all sources with enhanced functionality, described in the header of the servlet.
3. Debug the web application and make it work.
4. Email the sources as a zip file 4.3.4.ModifiedWebProject.Your.Name.zip
