Debugging tips you may not know

1. Remote debugging

Debugging is a necessary skill for developers, and we use it almost every day. But most of the time, we just debug the program on the local computer. Sometimes, local debugging cannot meet the debugging requirements. For example, due to the hardware and software differences between the local computer environment and the server environment, the local computer cannot reproduce the problem, so there is no way to debug and locate the problem. At this point, we may have a brainwave, can we directly debug the application deployed on the server? The answer is yes, you can install the corresponding development and debugging tools on the server, and then debug directly. In addition, you can also use local development tools to remotely debug applications deployed on the server.

The following is a brief introduction on how to perform remote debugging on the commonly used WebSphere (hereinafter referred to as was) middleware:

1. Set up remote debugging service on was (the following operations are all on was6.1.0.43):

Log in to the was console, Server->Application Server->Select the server where you want to enable the debugging service->Debug Service, check "Enable service at service startup", and restart the server.

was set

2. Set up on the local IDE (Eclipse, Version: Helios Service Release 2, Build id: 20110218-0911)

Eclipse settings

3. In the local IDE (Eclipse is used here, Version: Helios Service Release 2, Build id: 20110218-0911), right-click 'Debug As' and select the debug setting created in 2. Wait for the breakpoint on the server to be triggered, and then you can enter remote debugging, which is as smooth as local debugging.

For more information, see: Remote debugging Java applications using Eclipse

2. Front-end hack

There are often various problems on the server that cannot be presented in the local environment. It is really a life of endless troubles, and it is also a worrying monkey! Many times, various methods and techniques are used to locate the problem and find a solution. The local verification is passed, but more importantly, it needs to be verified on the server. As a running server, it is generally not allowed to be interrupted at will, and it cannot be easily updated and upgraded. So how can you perform server-side verification without changing the server? You can use the debugging function of the browser (this solution is only effective in some cases where you need to modify the front-end js, jsp and other codes).

For example: In the following code case, if the attachment name contains Chinese characters, garbled characters will appear when saving.

The file name is not encoded

The solution is to encode fileNameDes twice with encodeURIComponent. But how can we verify whether the problem is solved when the server does not allow temporary upgrades? Yes, this guy is right. You can use the monitoring function in the browser's F12 debugging function to directly change the variable value (set the methodPath variable to the value after being encoded twice with encodeURIComponent) to check and verify the final effect. Add the following code to the monitoring location (the effect is the same as the effect of uploading and deploying the *** code):

 methodPath = mainPath + "method=getDown&id=" +id+ "&fileNameDes=" +encodeURIComponent(encodeURIComponent(fileNameDes))+ "&fileName="   

Debugging and modifying variable values