Page 2 of 6
Read the sidebar "Stories from the Trenches" to see how AT&T fixed a bug in one of their programs.
First, you have to determine what code has to be patched. Sometimes it's fairly obvious and you will know the specific class or interface right away. If you feel you are too smart to be told how to locate the code, then by all means, skip to the section that talks about how to patch. Otherwise, sit back, relax, and learn several approaches to achieving the result.
The general method of locating a class to be patched consists of finding a starting point and navigating the execution sequence until you get to the code you want to change. If you do not encounter the code you want to change in the vicinity of the starting point, you must obtain a new starting point and repeat the process. A good starting point is crucial for quick results. Sometimes picking a class to start is fairly obvious. For example, for API or logic, patching the entry point would be the interface or class you want to change. If you want to make a private method of a class into a public method, the starting point is the class in question. If you need to fix a bug that results in a Java exception, the starting point is the class at the top of the stack trace.
A large, sophisticated system has dozens of packages and hundreds of classes. If you don't have a clear starting point, you
can easily get lost while trying to traverse the application logic. Think about the startup code for an application server
such as WebLogic. During startup, WebLogic performs hundreds of tasks and uses many threads to accomplish them—and even with
an unlimited supply of caffeine, I would not advise you to try to crack it by traversing from the weblogic.Server class.
The most reliable approach for such cases is a text-based search for a string that is known to be close to the target class. Well-written products and libraries can be configured to produce extensive debug information into a log file. Besides the obvious benefits for maintenance and troubleshooting, this makes locating the code responsible for the functionality in question easier. When you configure the application to write a detailed log of the execution sequence and a problem occurs somewhere, you can use the last successful (or the first erroneous) log message to identify the entry point.
As you might know, the bytecode stores strings as plain text, which means you can search through all .class files for a substring that you have seen in a log file. Suppose while using the security framework, an exception with the
text Invalid username is thrown on certain names. The reason for rejection is unknown and so is the solution. The easiest way to get to the code
if the stack trace is unavailable is by searching for Invalid username in all the .class files of the framework. Most likely, it will be one or two instances in the entire code, and by decompiling the classfile,
you will be able to understand the root of the problem. Likewise, you can search all the classfiles for a method or class
name, a GUI label, a substring of an HTML page, or any other string you think is embedded in the Java code.
Archived Discussions (Read only)