Skip to Content

NetWeaver Portal Debugging – 2, HotSwap your classes


The last NetWeaver Portal Debugging on Portal debugging by Karsten showed us the settings and procedure to start off debugging Portal components. This blog exhibits the HotSwap feature of Java which allows developers to change code pieces on the fly (while debugging) and see those changes reflected in their output. This provides significant productivity to developers because they then need not make a par and deploy each time they need to test a change. The Hot swap feature does not however come without limitations ,which I will cover ,further in the blog.

What is Hot Swap?

A rehashed quote : “Hot Swap aids in the runtime fix of an application by dynamic class loading and state transitioning through the Java debugger APIs” . This is currently supported on VMs greater than 1.4. More info available here

The screen shot below shows a collection renderer built on the Flex UI framework .The renderer is designed to show a list of blogs and each blog(based on xml content) respresented is by its 1.) title , 2.) abstract ,3.) date and 4.) author. Apparently there is a bug because of which the title is presented inplace of the abstract.

To test a fix ,launch remote debugging for the component through Eclipse and step to the break point (refer Karstens weblog) which holds the render method of the collection renderer. From the code its obvious that the title method of the Blog object has been reused inplace of the method that fetches the abstract. Inorder to test a fix ,the code can be changed in the debug mode itself and the debugger will relaunch the debug process of the class incorporating the change (on successful build of the class). In the above example though , it is obvious what the problem is but there are scenarios where the problem resoultion would require several trial and errors , that is where this technique is the most useful

1.)Erroneous code


2.) Code changed on the fly and rebuilt


3.) Output after code was fixed (No redeployment, only relaunch)





For successful update of the class file, the setting shown above is one of the options.This would mean on every save a rebuild will be performed or alernatively the project can be rebuilt manually (Ctrl +B) whenever a class reload is required.
Navigation path to this setting in Eclipse Windows->Preferences



The debugger would not be able to load the class if the shape of the class has changed meaning

  • Change in the name of class
  • Removing methods or method parameters
  • Adding or removing member variables
  • Changing code in an inner class

are not recognized and the debugger would complain about the code not being in sync with that present remotely

You must be Logged on to comment or reply to a post.