Creating a patch file with Apache Subversion

Apache Subversion is an open source version control system, popular among many developers. Creating and applying patches for your source code is a significant task you might need to do at some point of coding, specially when working with large scale enterprise product source codes. This post is about how to use subversion to create a patch or apply a patch after doing some modifications into the source code.

First let's see how to see the differences made into our code. 'diff' command is used to view the all the uncommited changes done into a certain project folder.

To view these uncommited changes goto the relevant directory in the local project repository and type;

svn diff

This will list all the modifications done into the source code with the specific class names.If we want to view the changes done to a single class or limited set of classes that can be viewed by adding those file names into our command as,

svn diff File1 File2 

But note that we have to be in the correct directory where the files are located, before entering the command.

Another option is view the differences between two revisions of the project.This is done by giving the specific version numbers with the 'diff' command.

svn diff -r revision1:revision2

As an example let's say we need to view the changes between revision 112 and 113. Then use svn diff -r 112:113, this will list the changes between the two given revisions only now.

As we can see the changes now next step is creating the patch file which contains these changes. The changes can be applied to the another source code using a .diff or a  .patch file. To create a patch for the modified contents in a whole directory, following command can be used.

svn diff > bug_fix.patch 

or

svn diff > bug_fix.diff 

If the patch is for some changes in a single file this can be,

svn  diff File1 > bug_fix.patch

There may be times that a patch is needed for the changes between two revisions. If so we need to give the necessary revisions with the command.

svn diff -r revision1:revision2 > bug_fix.patch

All the changes we did are safely written into a patch file now and they can be applied to someone else's code by applying this patch in the correct way.

Debugging Apache ODE Test Classes with Maven Surefire Plugin

There are some occasions when we need to debug the test classes in our unit tests base in the maven project. Ever wondered how to do that??  Well i did at the beginning when i had to debug the ODE test cases and that was when i found the way with maven surefire plugin. However this method can be used with any maven built project than ODE too.

Environment: Ubuntu 10.04 

                       Apache ODE 1.3.5 

                       Apache Maven 2.2.1 

                       Maven Surefire Plugin 2.5 

                       IntelliJ Idea 10.0.3

Here we go. Apache ODE's root 'pom.xml' file generally includes the maven surefire plugin by default as a test framework. The surefire 'debug' option is used to remotely debug the test classes in any of the modules in ODE project which is built using maven. First of all let's create a remote debug configuration with 'localhost' and default '5005' port, which is used by surefire. I have called mine as 'maven'.

Figure 1: Create a remote debug for Surefire

Now go to the specific module in ODE project directory in which we want to debug the test class. If you need to debug a single test class simply use the following command.

odeTrunk/bpel-compiler$ mvn clean install -Dmaven.surefire.debug -Dtest="CompilationMessageTest" -o

-Dmaven.surefire.debug : This tells maven to enable the surefire debug property and it will listen on default port 5005, for a remote debug connection to get attached.

-Dtest="CompilationMessageTest" : This command is used to declare the exact test class we need to debug. 

-o : Informs maven to build the module offline. If you need to build it online just remove the '-o' command.

When maven starts to build in debug mode we can see that it will hang on the console when waiting for a remote debug configuration as shown here.

Figure 2: Starting debug a single test class

At this time start the 'maven' debug in the IDE and it will pause at the given breakpoint in our 'CompilationMessageTest' class in the 'bpel-compiler'module.

Figure 3: Remote debug the test class

We don't have to declare a specific test class name under -Dtest command to debug that single test. Instead we can enable debugging for all the test classes and keep the breakpoint in the necessary class as our wish. In this case maven will run all the test classes in that module and will break at the specified breakpoint when it come to the relevant test class. The command for this should be;

odeTrunk/axis2-war$ mvn clean install -Dmaven.surefire.debug -o

A Visit to Sri Dalada Maligawa

Last week i had the opportunity of visiting the Sri Dalada Maligawa, which is a most sacred place to all of us Buddhists in Sri Lanka as well as all over the world. I was very exciting about the journey since it was my second visit to Kandy and also as we were travelling by train in the Observation Saloon for the first time(thanks to  my better-half <3).

Travelling to hill country by train was really a remarkable experience which one should have in the lifetime. Around 7.00 A.M in the morning we were at the fort railway station and the Colombo-Kandy Intercity Express train we were scheduled to travel by was already parked there at the platform. Since we were going in the observation car we had no difficulty in finding a place to sit. Because you have to book tickets in advance to travel in the observation saloon. FYI: Advanced ticket booking can be done by visiting any of the railway stations mentioned here in one month advance to the journey day. The prices of the train tickets for local visitors are varies as;

First Class Observation- Reserved: Rs 360.00

Second Class - Reserved : Rs 220.00

Third Class - Reserved : Rs 150.00

We came and found our seats as mentioned in our tickets. The saloon was very comfortable with fresh air, comfortable seats and luggage carriers. There were 24 passengers including us while some of them were foreign visitors and monks. While we were starting to get our breakfast inside, the train started the journey around 7.03 A.M. So here we come Kandy :)

It was said that the train only stops at Gampaha, Peradeniya and Kandy. Therefore the journey was very fast and untiring. We came out of the saloon during the journey and we were able to see many breathtaking sight scenes of the upcountry which we didn't forget to get caught as memorable snapshots. I noticed that the foreign tourists inside our saloon were also very keen and excited on getting photos of this great natural beauty. The following are some of the snapshots we could got during the journey.

We arrived Kandy at 9.35 A.M and the city looked busy as it was a working day. Dalada Maligawa is few meters away from the railway station therefore we started heading towards Maligawa once we came out of station. One has to pass the famous Kandy lake when going to the Maligawa and we also stopped there for a while. At the front gate, we bought fresh lotus flowers,oil and other things we needed to worship. Even it was a working day there were a lot of people inside, dressed in white had visited Maligawa to worship the sacred tooth relic of Lord Buddha.

The 'paththirippuwa' of the Maligawa is the first thing gets visible to someone who enters there. I was amazed at the beautiful view it made along with the mountain range behind and also was so filled with a great devotion towards worshipping the sacred tooth relic of Lord Buddha. We were fortunate to go to the 'Ihala Malaya' within the 'Thewawa'  time so we could worship 'Sri Dantha Dhatun Wahanse', before the 'Thewawa' was finished. We spent around 3 hours in the Maligawa worshiping and i can still remember how much my mind was relaxed at that time from participating various religious activities at this sacred place.

Before leave Maligawa we also went to the museum built for 'Raja' elephant who carried the sacred tooth relic in Dalada Peheraha for around 20 years. After having lunch, around 3.00 P.M, we headed back to the return Intercity train which was scheduled to come back to Colombo.   

WSO2Con 2011: A fantastic week with SOA, Open Source Development Trends and Cloud Computing

WSO2Con 2011, The second annual user conference organized by WSO2 is all set to begin from tomorrow with the participation of a whole set of local and international CEOs, Software Developers, Architects and  IT Managers gathered from all over the world. The event is compromised with three conference days   at Waters Edge Hotel, Battaramulla and two tutorials days. WSO2Conf 2011 is a whole event of guest speeches, customer experiences, tutorials and SOA best practices which will bring a remarkable experience to all its participants who has a great bond with open source developement community.

The conference week begins with a pre-conference tutorial day on 12th Sepetember 2011 at Taj Samudra Hotel,Colombo. This tutorial day covers most of the introductory tutorial sessions related to SOA and web services including Introduction to SOA, Introduction to WSO2 Carbon Platform, Introduction to Cloud Computing etc. 

Main conference is scheduled from 13th to 15th September at Waters Edge, which will bring an overall experience of getting familiar with the innovative WSO2 product stack as well as many SOA and Web Services related technologies from guest speeches from well known software professionals in the world. 

The conference may end with a post-conference tutorial day on 16th September at Centre for Banking Studies, Kotte. Post-conf tutorials cover some advanced aspects of WSO2 products and technologies.

Corresponding to the event, selected 50 local university students have given a valuable opportunity of participating WSOConf 2011 under a highly affordable package, which will surely give a value added opportunity to their carriers and interests. Although i am still a university student, i was very fortunate to participate the whole conference week for free as a team member due to my internship at WSO2 at the moment. I specially hope to participate on  'Introduction to OSGI' and 'Introduction to Web and SOA Security' sessions which i hope as essentials in getting familiar with WSO2 products. Also very much looking forward to attend in 'Advanced Concepts in WS-BPEL' session presented by my team members of WSO2 BPS team.  

Read the whole list of the tutorial sessions and conference days agenda here.

Here are the key speakers who are going to address WSO2Conf 2011.

The location information is available here.

Inviting all the participants to have a wonderful Con Week in Sri Lanka :) 

Remote Debugging Apache ODE with Apache Tomcat Server in IntelliJ Idea

Apache ODE (Orchestration Director Engine) can be deployed and run in three different environments. One of them is deploying ODE as a web service in Axis 2, by deploying the ode war distribution inside an application server like Apache tomcat. Once it is deployed and started you may need to debug ODE, to understand what is going inside the engine. The following is a short guide on how to debug Apache ODE with tomcat in both Windows and Linux environments.

If you don't know how to deploy ODE and run with Apache tomcat first visit and read the this previous blog post.

Applicable with:

Apache Tomcat : 7.0.11    Download 

Apache ODE: 1.3.5           Download

Debug ODE in Ubuntu 10.04

Apache Tomcat can be debugged with JPDA debugger by starting tomcat with catalina script. To do this start go to Tomcat_Home/bin folder and enter the following command.

apache-tomcat-7/bin$ sh catalina.sh jpda run  

This will start catalina server in debug mode and you can see it displays the message, "Listening for transport dt_socket at address: 8000" in terminal as shown in Figure 1.

Figure 1: Starting tomcat in debug mode

Another method would be setting the JAVA_OPTS to start up java for listening to debugger connections by giving,

apache-tomcat-7/bin$  export JAVA_OPTS=

"-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000"

When it is set start the catalina server in the usual manner as 'sh catalina.sh  run' and tomcat will be started in debug mode.   

Now we can create a remote debug configuration by giving Host: localhost and Port: 8000 in our IDE which we have used to open the ode source code, and debug ODE by using that. Remember to use the same port used as JPDA_ADDRESS in tomcat as your IDE's remote debug port. The default port address is 8000.

Creating a Remote Debug Configuration in Idea 10.0.3

This is how to create a remote debug with IntelliJ Idea 10.

• Go to Run --> Edit Configurations in the IDE

Figure 2: Creating a Remote Debug Configuration

• When it is selected the Run/Debug Configuration window will pop up.  Click the  icon there and select 'remote' from 'Add New configuration' menu.

Figure 3: Created New Remote Debug

• This will create a new remote debug configuration for us. Let's name it as 'ode' and fill the Host field with 'localhost' and Port field with '8000'. Then click OK.

Figure 4: Setting up Host and Port for remote debugging

• The new remote debug is successfully created now. After the tomcat server is started, select 'ode' remote debug and start it by clicking icon in Idea. It will connect to the server via the defined port and you can start debug ODE now.

Figure 5: Debugging ODE

Note: port 8000 is the default port address used in tomcat for JPDA debugging, however if port 8000 is busy(due to some other application running there), you can change it into another port. 

• Open catalina.sh script in the Tomcat_Home/bin folder and search for JPDA_ADDRESS, you will see JPDA_ADDRESS="8000" defined there. Change it to any available port and restart tomcat under JPDA debugger. The server will listen from the new address now.

Figure 6: Edit the JPDA_PORT in catalina script

         You can also change this port (let's say to 8010) by giving,

         apache-tomcat-7/bin$ export JPDA_ADDRESS=8010 in terminal.

• Now go back to the 'ode' remote debug and select 'Edit Configurations' to edit its configurations.

Figure 7: Edit the remote debug configuration in Idea 10.0.3

• When Debug Configuration window appears set the Port address into the modified port,8010. Once it is set ODE can be debugged using the new port again.

Debug ODE in Windows

Debugging in Windows is also very similar to in Linux, except the commands that should be used. All the following demonstrations are performed in Windows 7 version.

• To start tomcat, go to the tomcat home's bin folder and start catalina.bat file under jpda debugger as follows.

C:\Apache-Tomcat-7\bin> catalina.bat jpda start

Now catalina will start in remote debugging mode under JPDA debugger using its default port 8000. When it is started you will see tomcat starts a new debug console as shown below in Figure 8.

Figure 8: tomcat Debugger Console in Windows 

This can be also done by setting an environment variable  JAVA_OPTS, and starting the tomcat server with usual command.

C:\ Apache-Tomcat-7\bin>  set JAVA_OPTS=

"-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000"

C:\Apache-Tomcat-7\bin> catalina.bat run


When it is started create a new remote debug configuration as described in the previous section by configuring the correct Port address and Host. Once the remote debug configuration is connected to the server, you can debug ODE successfully.

Note: To change the port address from 8000 to another port 'set' command can be used in Windows. Go to Apache-Tomcat-7\bin and enter;

C:\ Apache-Tomcat-7\bin> set JPDA_ADDRESS="8010"

Figure 9: Change JPDA_ADDRESS in tomcat

When tomcat is started again you will see that it has changed the listening port into '8010' as we changed. Change the Port address in the remote debug into this new address and start debugging again. 

Figure 10: Debugging tomcat in Different Port

JPDA_ADDRESS can be also changed from the catalina.bat file in Windows. Right click catalina.bat file and select 'Edit' option from the menu. Then the file will be opened using Notepad or some other text document opening application in Windows. Search for JPDA_ADDRESS and change its value into a new one. Save the file back and start tomcat again.